Effective C++を読んでいる。

どうもJudaです。
読んでいるのだけど、この本はとてもためになる。
『Exception C++』を読むための門前本として紹介されていてEffective C++を読んだらExceptional C++の良さがわかったCommentsAdd Star、「なるほどなるほど」と思って、読み出しました。
C++という言語などのプログラミング言語を使って生活をしているのですが、ちゃんと理解していないでいたこと、どういうプログラミングをすることが流儀に従うのかということについてのちゃんとした知識を得られるのが実にいいです。
もっとも自分のプログラマとしてのレベルが足りないので、この本ですら、読むのが少し大変ですw

最近気づくこと

どうもJudaです。
最近思うのですけど、世の中にはすぐにできないと言ってしまう人が多いのですね。
例えばそれがハンダ付けであったり、電子工作のためのパーツ選定であったり、数学的な理論の読解であったり、英語の読解であったり、経済の勉強であったり、法律の問題であったり、権利関係の書籍の読み込みなど。
飛び込んでしまってから考えようとか、命が残るからやってみようとか、そういう感じは一般的ではないのですね。
私はなんだかんだと口ではそれが如何に難しいのを留保してから、結局いろんなものに手を出しますね。そうしないでいることによって選択肢が狭くなるのが嫌なのです。
でもなかなか人間関係には飛び込めない。唯一これだけは無理ですね。
失敗した場合に、多少なりともこの問題は死を呼びこむので個人的に苦手です。一番怖いのは人間です。

理由はわかっているけれど、やってしまう間違い

どうもJudaです。
今日はXMLシリアライズな話

using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.Serialization;
using System.IO;
using System.Xml.Serialization;

namespace SerializeDaemon
{
 class Program
 {
  static void Main(string[] args)
  {
   XmlSerializer xmlSel = new XmlSerializer(typeof(Deamon));
   StringWriter wStrm = new StringWriter();
   Deamon hoge = new Deamon();
   xmlSel.Serialize(wStrm, hoge);
   Console.WriteLine(wStrm.ToString());
  }
 }
 public class TestA : ISerializable
 {
  protected int m_id = 0;
  public TestA() { }
  public int Id
  {
   get { return m_id; }
   set { m_id = value; }
  }

  #region ISerializable
  protected TestA(SerializationInfo info, StreamingContext context)
  {
   m_id = info.GetInt32("Id");
  }
  public void GetObjectData(SerializationInfo info, StreamingContext context)
  {
   info.AddValue("ID", m_id);
  }

  #endregion
 }
 public class TestB : TestA
 {
  public TestB() : base() { }
  protected TestB(SerializationInfo info, StreamingContext context) : base(info, context) { }
 }
 public class TestC : TestA
 {
  public TestC() : base() { }
  protected TestC(SerializationInfo info, StreamingContext context) : base(info, context) { }
 }
 public class Deamon : ISerializable
 {
  TestA m_id0;
  public TestA Id0
  {
   get { return m_id0; }
   set { m_id0 = value; }
  }
  
  TestA m_id1;
  public TestA Id1
  {
   get { return m_id1; }
   set { m_id1 = value; }
  }

  TestA m_id2;
  public TestA Id2
  {
   get { return m_id2; }
   set { m_id2 = value; }
  }

  public Deamon()
  {
   m_id0 = new TestA();
   m_id0.Id = 100;
   m_id1 = new TestB();
   m_id1.Id = 4000;
   m_id2 = new TestC();
   m_id2.Id = 6000;
  }
  protected Deamon(SerializationInfo info, StreamingContext context)
  {
   m_id0 = (TestA)info.GetValue("ID0", typeof(TestA));
   m_id1 = (TestA)info.GetValue("ID1", typeof(TestA));
   m_id2 = (TestA)info.GetValue("ID2", typeof(TestA));
  }

  #region ISerializable

  public void GetObjectData(SerializationInfo info, StreamingContext context)
  {
   info.AddValue("ID0", m_id0);
   info.AddValue("ID1", m_id1);
   info.AddValue("ID2", m_id2);
  }

  #endregion
 }
}

コンパイルは通るけれども、実行はできないソースコード。
問題点は、シリアライズ対象のクラスがもっている要素に継承クラスが代入されていること。これはシリアライズにおいて、とても大変な問題をはらんでいる。
サブクラスをシリアライズする方法なんてわからないのだから。
シリアライズという行為が現状を復元可能な形で保存することにあるときに、継承クラスかどうかの判定なんて誰がどうやってするんだろーって事で原理的に今は無理です。柔軟に対応しないといけないならば、むしろ別の方法でそれを実現する方法を探す方が賢いと思います。あるいはできるなら、それを教えてください。
とりあえずは素直にすべての要素が構造体で定義されているものをシリアライズするコンテナクラスとして使用しましょう。というお話です。

細かな点ですが、インターフェイスはコンストラクタを規定できないので、実はISerializableの実装はちゃんとコンストラクタを特別に作っておかないとダメです。
ややこしいですねー。

C#でMathematicaなIntervalの実装

どうもJudaです。
とりあえず掲題の内容を行う。
なぜ作るのか？それは必要だから。
Random関数を範囲で分散する方法に切り替えようと思うと、どうしてもIntervalって感じの区間計算クラスが欲しくなった。それ以外の用途でも、特定の定義域に値が存在しているか、いないのかを簡単なインターフェイスで取得できることをとても便利であり、よくある処理なので、これをつくる。
BoostのIntervalのAPIを参考して、なんとか作るつもり。本当に数学的な意味でのIntervalの実装は面倒なので、使い易い部分のみをサックリと。
昔似た機能のLimitというGenericClassをつくったけど、それはSerializeのためのSyntaxSuger的な糖衣クラスだったので、ちょっと今回はかっちり作ってみつつ、Serializableも目指す。
細かなクラスや機能ばかりを作っている気もするが、気にしない。大きな建築物を作るには細かな道具の手入れや資材の準備に時間を惜しまない。すべて我が血肉になるのだから。

画像処理ライブラリ

どうもJudaです。
画像処理ライブラリは汎用性が高くて、使用頻度も高く、なおかつ逐一スクラッチで作るにはめんどうで、それでいて速度が求められて、細かな仕様に左右されることの多いライブラリだと最近思います。
例えばOpenCVのRGBコンポーネントの内部的な配置はRGBではなくBGRであるなど（一応内部的にRGBへ変換する関数が存在するようですが）コンポーネントの問題があり、その画像がRGB24なのかRGBA32なのか、それともGrayScale１６なのかGrayScale32なのかYUIなのかHSVなのかなど色空間の問題もあります。
それらすべてに汎用的なものを用意するのは、非常に困難であり、通常画像処理ライブラリはRGBでの画像処理をもとに考えられています。もっともこれ自体は特にプログラマにとって問題なく読替を効かせることのできるものです。問題はそのライブラリは高速にすることや、面倒を回避するために汎用化することです。
一部細かな話しですが、.netでのImageの操作は通常はメソッド経由なので、オーバーヘッドが尋常ではないので、特定の一点から取得するなどのアクセス頻度の低い作業以外は、なるべく低レベルな操作で構築する必要性があり、BitmapのLock/Unlockは.net系の画像処理では必須であり、これはコンポーネントの構成に大きく左右されるので、通常のマネージドな感覚で行っていると速度の低下が発狂せんばかりになります。Lock/Unlock以外にもUnsafeでガリガリ行う方法もありますが、移植性が下がるので、なるべくそれはやめた方がよいです。それに性能もそれほど向上しないので、最終手段として覚えて置く程度でいいと思います。
話は戻りますが、画像処理は速度と精度と汎用性、多種多様性、移植性、利便性など多くの点が求められるので、なかなか構築が面倒なのですが、作ることは非常に有益だと考えます。
またコンセプト的な嗜好も混ぜ込めるので、個人的にはある程度以上のレベルからは自己のライブラリとして蓄積することを考えてしまいます。
そうするとオープンソースがとても魅力的ですが、仮にこれを業務で特定のアプリケーションに組み込もうと思うと商用ある程度のライセンス料が必要です。そもそも煩雑で有用な知識の集積は、その労力によって企業による上澄みの簒奪を唾棄し、その行為への怒りをこめて、オープン化する場合もあるので、有用なものを安く使いたいという心とライブラリの制作にかかるコストを最低限でも回収したいというジレンマがよくわかります。個人で開発しだすとよくわかります。
だから個人で開発しだしても、やはり企業に差し出すなどということは許容できないなぁと思います。

企業はもっとライブラリライセンスに金を払えやこらー！っていうのがある意味本音です。安くあがる分けねぇだろ、知識の集積を利用しようとしているのに。

読書と筋トレ

どうもJudaです。

読書と筋トレを私はほとんど同列の行為だと時々認識します。
どちらも自己を研鑽する目的があります。読書も本によって内容に強度がありますし、難しい本はやはりベンチプレス200kgのような困難さがあります。しかし読書や筋トレを好む人は、その困難さを楽しみに変えますし、それが嫌いな人は、その困難さが嫌いなのです。運動を頑張る人が勉強を頑張れないというのは、結局はこの困難さがあるということを知らずにいた人なのだろうなぁと思います。私は、個人的にその感覚を養うことができないことはもったいないと思います。ただなにかに頑張るにしても、良き指導者がほしいのは変わりませんが。

さらに読書と筋トレから同様の枠組みを取り出すならば、それは「不自然な行為を自然な行為に変えていくこと」ということでしょうか？読書は通常の人間の営みからすると不自然です。この場合の不自然は意図をもって行動を行わなければならない。ということです。同様に通常の人間の営みからすると筋トレは不自然です。明確な意志や意図をもって行わなければ、それを行うことはないでしょう。

私はこの意図や意志というものを高く評価しています。それは哲学科という日本では非常に特異な分野を専攻していたことに起因するのですが、国外ではこの意図や意志というものはごくごく一般的な教養ある人の中では当たり前であり、意思決定においてこれがないとまっとうではないです。

日本で、ある決定について、「それはどうしてですか？」という根拠を訊くことは野暮ということになっています。それはほぼ均質な文化的な基盤があるという前提が確立しているからですが、現在の日本において個々人の文化的な基盤がほぼ確定的に共通であると信じる根拠に乏しいと思います。ゆとりと称される存在は明らかに文化的な基盤が共通であるとは考えられない人への別称です。このカテゴリにはいる存在に対して、ただ闇雲に「若いヤツは」的な話をするのは、愚かしさの上塗りです。彼らも確かに生きてこの社会に存在しているのですから、その「貧弱」にみえる文化基盤でも問題はないのです。

話は戻りますが、意志や意図をもって何かを行うことは悪いことではないですし、それは非常に強い決定であると考えます。意志や意図はしばしば「悪いこと」をしたときには訊かれます。「どうしてそんなことをしたんだ！」など、見に覚えがあると思いますが、私からすればその理由が答えられるならば、その人は明確な意図をもって行っているので、容易く答えられますが、ただなんとなく行ってしまったというときに失敗する事は多いと思います。

つまり通常時は意志や意図を求められることがないのに、失敗した時だけ理由を訊かれることは、個人的に気分最悪です。意思決定をして、行動を起こす前でなく、その結果のみに対して詰問を行う姿勢は、非常に合理的でシステム的にも無駄がないのですが、それが常態化したときに十分な結果に対する責任をもつという姿勢が養えるのかは分かりません。それに失敗は失敗として既にマイナスでしかなくて、詰問の回答によってはさらにマイナスが膨らむとすれば、誰がまっとうに答えることができるようになりましょうか？

行動の意図や目的を問うことも必要ですし、成功、失敗にかかわらず、結果に対しても常に意見を求めることがこれからの在り方として必要ではないでしょうかねぇ。

ControlController

どうもJudaです。
.net Frameworkをつかって、フォームをデザインするときにでるあの特別なコントローラーが気になります。
あれがとってもほしいのです。
考えられる方法は幾つかありますが、C#,VBがOOPと言えども、言語的にクラスの継承の間に割り込みはできないので、委譲のほうで問題を回避していくことが重要かもー。
コントロールを入れられるコントロール制御用のコンテナを用意して、そのコンテナに対して制御を加えるようにすれば、汎用的にコントロールを扱えますね。うん、というか、それ以外に思いつきません。
調べたところ、既にこのコントローラを開発した人もいるのですが、2003で作られているし、またこれに限っては車輪の再発明も幾分か自己のOOPへの理解や修練に役立つので少し試行してみる。

取り替えずコンテナをクラスで宣言します。描画の関係もあるので、Controlを継承した方が無難なので、継承する。ただここで考えるのは、
・これにコントロールを入れて、
・Mouse系のイベントを使うこと、
・Key系のイベントでの制御も許容すること。
・同時に周りのコントロールとの数値の関係性によって拘束がかかること。
・選択時には特別な描画処理を行うので、Paintイベントも書くこと。
意外と使い易いコンテナをつくるには問題がありそうだ。
コントロールをコンテナに格納したときに、格納したクラスの個別のマウスやキーのイベントをハックしないといけないので、これが若干気になりますねー。コンテナ格納後に個別のコントロールのイベントが生きていると困るので、殺しておきたいのですが、よくわからないのであとで調べておきますね。
たぶん内側を透明にしてZバッファの順序を入れ替える。もしくはフォーカスイベントが発生するとフォーカスを移すとかですけど、フォーカスのイベント内でフォーカスを移動させると予想外の動きをするので、あまりおすすめできません。以前、実験した際に、呼び出しが規則的に発生しないことを確認したので、フォーカスを制御するのは、確実性に疑問があるので、別の方法を模索するほうがいいです。
あとはコントロールが登録されているものを入れ替えてしまうかですが、これはデータの構造を勝手に書き換えることになるので、おすすめできません。汎用性にかけることは間違いないので、なるべく同一の階層性でイベントの登録のみで解決したいですね。
…別にコンテナを開発しなくても、イベントの登録、削除をうまく制御すれば、データ構造的な面では出来そうですが、すでに存在しているイベントとぶつかったり、そもそももとのイベントが駆動してしまう問題があるので、これはうまくいきそうにないです。
ここまでの問題点で一番大きいのは、コントロールに発生するイベントを一時的に殺して、それをバイパスして別のコントールに移すことができるのかどうかです。そのあとは、ここの機能を分割しながら実装していけば問題はなし。
初回ではなく、選択後つまりコンテナに入れられた後に、そのあとは独占的にコントロールを支配できなければいけません。なにか方法はないものでしょうか？

コンテンツ、コンテナの話

どうもJudaです。
今回はコンテンツとコンテナの話を。
コンテンツをオリジナルでユニークなそれ自体では複製できないモノとします。それが「なにか」ということについては議論しません。
コンテンツをコンテナに格納すれば、複製可能になるとします。またコンテナに格納されたコンテンツを、別のコンテナに移し替えるこが出来るかどうかは、コンテナの性質になります。
想定している対象物はDVDやMP3です。
コンテナからデータを取り出せないのでは意味がありませんが、このコンテナがコンテンツを完全に取り出せることは保証しません。ただコンテナの存在意義としてそれがあまりにはコンテンツを損傷させるのでは意味がありません。完全に復元可能なものを特別にロスレスという形容をする場合があります。この場合にロスはコンテンツが本来持つ性質を損失しないという意味です。
問題を局所化します。
DVDはコンテナであり、それが内包しているコンテンツが映像やデータになります。通常の販売者はコンテンツをコンテナにいれて、販売します。ただし、このときにコンテンツを売る気はさらさらないです。このコンテンツをコンテナにいれて複写して販売しているので、コンテンツを売ってしまうと困ります。
しかし購入者はコンテンツを購入したと思います。このコンテンツを取り出し、別のコンテナに入れること、複写という行為を含めて権利だと考えます。この時点で既に販売者と購入者の間で意見の相違があります。売買契約から考えると販売者が優位です。このことは既に周知だと思われます。
コンテンツを鑑賞させるけれども、別のコンテナの中にいれることを認めないということは、映画でも同じです。またラジオでも同じです。別のコンテナに入れるときに、コンテンツの作成者は対価を求めます。
さてさてややこしいのは、コンテナとコンテンツは、その構造が入れ子になりうることにあります。この性質のために本来のコンテンツの製作者と利用者の間に介在する存在があることが想定されます。これがもっともややこしい。
すべてのコンテンツの製作者に権利を認めると、その入れ子構造のせいで最終的な利用者以外はすべて権利を持つことになります。オリジナルのコンテンツとしての権利を持つ人ほどそれが無断でコンテナに入れられることに対して、対価請求の機会を損失します。
では本来のオリジナルのコンテンツの制作者からそのコンテンツの権利を手にいれるということは可能か？
これは今までの議論をすっ飛ばしているが、コンテンツの売買というコンテンツの本質に対する問いかけなのだが、これが著作権の本質に直結する。またオリジナルを誰が所有するのかということにもつながる。
オリジナルの所有の問題はもっともややこしい。同一性の問題にもつながり、そこには正統性の話も関わる。正統性の話は歴史の問題であり、そこまで来るならば、それが根ざした背景や環境、文化すらも範囲に入ってしまう。仮に問題を簡素にするなら、何を売っているのかぐらいだろう。
結論から言えば、売っているのはコンテンツをコンテナに詰めることの独占的な販売権だけだろう。
権利というものは、あとから生まれた人為的なものであることを心に止めて置くことが必要だし、それを踏みにじることの代償についてはもっと配慮すべきだ。