int id = projects.Find(projectName).GetID(); // プロジェクト名から ID を取得

そして、このコードをデメテルの法則に違反しないように書き換えると、次のようになる。

int id = projects.GetID(projectName); // プロジェクト名から ID を取得

変更後のコードは Find が返すオブジェクト（ここでは多分 Project みたいなクラス）に依存していないので、オブジェクト間の結合度が下がったことになる。結合度の低いプログラムは良いプログラムであり、デメテルの法則に従えば良いプログラムになるというわけだ。

でも、ちょっと待って欲しい。

例えば、Project クラスに次のようなメンバ関数が含まれていたとする。

class Project {
public:
  const std::string& GetName() const; // プロジェクト名
  int GetID() const; // ID
  const std::string& GetDescription() const; // プロジェクトの説明

  //...
};

先ほどは GetID だけで済んだが、当然の流れとして GetDescription も Projects のメンバにすべきという話になるはずだ。

class Projects {
public:
  int GetID(const std::string& name) const; // プロジェクト名 → ID
  const std::string& GetDescription(const std::string& name) const; // プロジェクト名 → プロジェクトの説明

  //...
};

つまり、デメテルの法則に従って Projects クラスを定義していくと、Project にメンバが追加される度に Projects メンバの追加を検討することになる。

実際に Project に「メンバ」を足してみることにしよう。

class Member {
public:
  const string& GetName() const;

  //...
};

class Project {
public:
  const std::string& GetName() const; // プロジェクト名
  int GetID() const; // ID
  const std::string& GetDescription() const; // プロジェクトの説明
  const Member& GetLeader() const; // リーダは一人だけ
  const std::vector<Member>& GetMembers() const; // 全メンバ（リーダも含む）

  //...
};

メンバ違いなのはさておき、Projects からプロジェクトリーダやメンバの名前を取得するようなコードは、デメテルの法則に従えば次のようなものになるはずだ。

string leaderName = projects.GetLeaderName(projectName);
vector<string> membersName = projects.GetMembersName(projectName);
// or
string memberName = projects.GetMemberName(projectName, index); // 一人ずつ取得しても良い

これを実現するためには、Projects クラスに GetLeaderName, GetMembersName あるいは GetMemberName といった関数を追加しなければならない。

class Projects {
public:
  int GetID(const std::string& name) const; // プロジェクト名 → ID
  const std::string& GetDescription(const std::string& name) const; // プロジェクト名 → プロジェクトの説明

  // プロジェクト名 → プロジェクトリーダ名
  const std::string& GetLeaderName(const std::string& name) const;

  // 全メンバ（リーダも含む）の名前を一括で取得する
  // （他にも色々な実装が考えられるが、今回の話題ではこれで充分）
  const std::vector<std::string>& GetMembersName(const std::string& name) const;

  // こちらの方が「戻り値のメンバを使わない」という観点から、より LoD 的な実装
  std::size_t GetMemberCount(const std::string& name) const; // メンバの数
  const std::string& GetMemberName(const std::string& name, int index) const; // メンバ名

  //...
};

以降、同様に Projects のメンバは肥大化の一途をたどることになる。私が Projects クラスのユーザなら「もう、いっそのこと Project に依存させてくれ！」と叫んでいるところだ。（そして多分 Member クラスも同じ理由で依存したくなるはず。）

さらに、Project や Member のインタフェースだけが肥大化の要因ではない。

プロジェクト名から何らかの情報を得るというインタフェースの他に、プロジェクト ID からも情報を得たいという要求が挙がった時のことを考えてみよう。デメテルの法則に従えば、プロジェクト ID をキーにした一連のメソッド群を用意すべし、となる。

class Projects {
public:
  int GetID(const std::string& name) const; // プロジェクト名 → ID
  const std::string& GetDescription(const std::string& name) const; // プロジェクト名 → プロジェクトの説明
  const std::string& GetLeaderName(const std::string& name) const; // プロジェクト名 → プロジェクトリーダ名
  const std::vector<std::string>& GetMembersName(const std::string& name) const; // プロジェクト名 → 全メンバ名
  std::size_t GetMemberCount(const std::string& name) const; // プロジェクト名 → メンバの数
  const std::string& GetMemberName(const std::string& name, int index) const; // プロジェクト名 → メンバ名

public:
  int GetName(int id) const; // ID → プロジェクト名
  const std::string& GetDescription(int id) const; // ID → プロジェクトの説明
  const std::string& GetLeaderName(int id) const; // ID → プロジェクトリーダ名
  const std::vector<std::string>& GetMembersName(int id) const; // ID → 全メンバ名
  std::size_t GetMemberCount(int id) const; // ID → メンバの数
  const std::string& GetMemberName(int id, int index) const; // ID → メンバ名

  //...
};

以降、検索のキーが増える度に、同様のインタフェースが追加されることになる。

もし、デメテルの法則に従わなければ、先ほどのコードは次のようになっていたはずだ。

class Projects {
public:
  const Project& Find(const std::string& name) const; // プロジェクト名 → Project クラス
  const Project& Find(int id) const; // ID → Project クラス

  //...
};

これなら Find の種類が増えても Projects のメンバ関数はそれに応じて増えるだけだし、Project のメンバが増えても Projects に影響はない。先ほどよりも遥かに直交性の高いプログラムになっている。

そもそも Projects というクラスは Project を一括して管理するという役割を担っていたはずだ。リーダ名を取得するメソッドが「Project を一括して管理する」という役割に沿ったものだろうか。いや、とてもそうは思えない。こういった、クラスの役割とは異なるメンバ関数が多く含まれるクラスのことを凝集度が低いクラスと呼び、デメテルの法則に従って改変した Projects クラスは凝集度が低いクラスに変化したことになる。

ちなみに、Projects が Find によって Project を直接返すなら、プロジェクトリーダの名前を取得するコードは次のようになるだろう。

string leaderName = projects.Find(projectName).GetLeader().GetName();
// あるいは
string leaderName = projects.Find(projectID).GetLeader().GetName();

まさに「デメテルの法則違反」なコードだ。でも、私は Projects が肥大化するよりはこの方がマシだと思えるのだが、そういった感覚はおかしいのだろうか？ 直交性を犠牲にしてまで従うべき法則なのだろうか？

デメテルの法則に従うと得られるメリットは以下の通り。

• 依存するクラスの数を減らすことができる（結合度の低下）
• 中間部分のインタフェースが変更されても、呼び出し側のコードを変更する必要がなくなる
• 中間クラスが持つ不要なインタフェースを隠蔽できる（むしろ隠蔽すべき）

これに対するデメリットは以下の通り。

• クラスの役割があいまいになる（凝集度の低下）
• 場合によってはラッパーメソッド（委譲に必要なメンバ関数）が大量に必要となる

結局のところ、メリットとデメリットのトレードオフなだけであって、闇雲にデメテルの法則に従う必要はないはずだ。「それ、デメテルの法則に違反してるよ」と言われた時に、「それでは、直交性や凝集度を考慮した上でクラスのインタフェースを再検討してみましょう」と言ってみるのも面白いだろう。

極端な話、以下のコードだってデメテルの法則に違反している。

vector<Member> members;
//...
for (size_t i = 0; i < members.size(); ++i)
  cout << members[i].GetName() << endl;

そう見えなければ、こう書き換えてもいい。

vector<Member> members;
//...
for (size_t i = 0; i < members.size(); ++i)
  cout << members.operator[](i).GetName() << endl; // ドットが2つ！ LoD 違反！

これをこう書き換えればデメテルの法則を違反せずに済むが......

for (size_t i = 0; i < members.size(); ++i) {
  const Member& member = members[i];
  cout << member.GetName() << endl; // OK. ドットは一つだけだ
}

それを強制させられるような職場なら、本気で転職を考えたほうが良いだろう。

参考文献

The Paperboy, The Wallet, and The Law of Demeter (PDF)

このエントリが LoD に批判的なものになってしまったので、肯定的な文献を参考に挙げておく。英文だが、現実の世界をモチーフにしたサンプルコードが分かりやすく、英語そのものも読みやすいのでお奨め。

今回は意図的に LoD に不利な条件を作り出したが、隠蔽すべきものは隠蔽するというカプセル化の大原則を忘れてはならない。トレードオフを考えつつ、LoD に従うべきときは素直に従うべし。

まずは、次のようなコードから。

public ref class Base // ref class なので参照型
{
public:
  generic <typename T> // generic を仮想関数につける
  virtual int Func(T in) { // T は任意の型
      return sizeof(in); // T 型のサイズを返す（本当は size_t だけど）
  }
};

public ref class Derived: public Base
{
public:
  generic <typename T>
  virtual int Func(T in) override { // Base::Func を override
      return sizeof(in) * 2; // T 型のサイズを倍にして返す
  }
};

これはTがどんな型であっても正しく動作する。Derived のインスタンスを Base のハンドルで参照しても、Derived 側の Func が呼ばれる。完璧だ。

C++ では、Tの型が決まらないと仮想関数テーブルを構築できず、Tの型を知るためには全ての翻訳単位を調べなければならない。よって、このようなメンバ関数は禁止されている。そして、以前のエントリでは「なんだ、その都度 JIT コンパイルすればいいじゃん」という結論で終わっていた。今回は、これをもう少し調べてみようと思う。

ということは、C++ の「仮想関数テーブル作成問題」は、この MSIL を作成する段階で問題にならないだろうか。先ほどのコードを ILDasm で見てみると、このようなコードになっていた。

.method public hidebysig newslot virtual 
        instance int32  Func<T>(!!T 'in') cil managed
{
  // Code size       9 (0x9)
  .maxstack  1
  .locals ([0] int32 V_0)
  IL_0000:  sizeof     !!T
  IL_0006:  stloc.0
  IL_0007:  ldloc.0
  IL_0008:  ret
} // end of method Base::Func

.method public hidebysig virtual instance int32 
        Func<T>(!!T 'in') cil managed
{
  // Code size       11 (0xb)
  .maxstack  2
  .locals ([0] int32 V_0)
  IL_0000:  sizeof     !!T
  IL_0006:  ldc.i4.2
  IL_0007:  mul
  IL_0008:  stloc.0
  IL_0009:  ldloc.0
  IL_000a:  ret
} // end of method Derived::Func

よく見ると、なんと T が T のままコンパイルされている。そして、sizeof が T をそのまま処理している。MSIL のレベルで T を T として扱っているということは、JIT コンパイルの段階で T の型に応じたネイティブコードを生成可能ということ。なるほど、ここまでは予想通り。

でも、これは MSIL の sizeof が T を T として扱えることに頼っている。sizeof じゃなかったらどうなるのだろう。

public ref class Base
{
public:
  generic <typename T>
  virtual System::String^ Func(T in) {
      return in->ToString(); // 今度は T に対して ToString メソッドを呼び出してみた
  }
};

public ref class Derived: public Base
{
public:
  generic <typename T>
  virtual System::String^ Func(T in) override {
      return in->ToString() + " (Derived)"; // Derived 側の処理も上書き
  }
};

今度は T 型の変数 in に対して ToString メソッドを呼び出してみた。ILDasm の出力は次の通り。

.method public hidebysig newslot virtual 
        instance string  Func<T>(!!T 'in') cil managed
{
  // Code size       16 (0x10)
  .maxstack  1
  .locals ([0] string V_0)
  IL_0000:  ldarga.s   'in'
  IL_0002:  constrained. !!T
  IL_0008:  callvirt   instance string [mscorlib]System.Object::ToString()
  IL_000d:  stloc.0
  IL_000e:  ldloc.0
  IL_000f:  ret
} // end of method Base::Func

.method public hidebysig virtual instance string 
        Func<T>(!!T 'in') cil managed
{
  // Code size       26 (0x1a)
  .maxstack  2
  .locals ([0] string V_0)
  IL_0000:  ldarga.s   'in'
  IL_0002:  constrained. !!T
  IL_0008:  callvirt   instance string [mscorlib]System.Object::ToString()
  IL_000d:  ldstr      " (Derived)"
  IL_0012:  call       string [mscorlib]System.String::Concat(string,
                                                              string)
  IL_0017:  stloc.0
  IL_0018:  ldloc.0
  IL_0019:  ret
} // end of method Derived::Func

IL_0008 の部分で、callvirt という命令を使って Object::ToString() を呼び出している。この部分に T はなく、T は1つ前の constrained で使われている。T がどんな型であっても constrained が良きに計らってくれて、実行時の型に応じた ToString() が呼ばれるというわけだ。すばらしい。

ToString は System::Object のメソッドなので、どんな型からも（場合によってはボックス化を伴って）呼び出すことができる。もう少しハードルを上げてみよう。T という型が持っている「かも知れない」メソッドを呼び出してみたらどうだろう。

public ref class Base
{
public:
  generic <typename T>
  virtual System::String^ Func(T in) {
      return in->Func1(); // エラー: T は System::Object と見なされるため、Func1 は呼べない
  }
};

public ref class Derived: public Base
{
public:
  generic <typename T>
  virtual System::String^ Func(T in) override {
      return in->Func2(); // エラー: Func2 も System::Object のメンバではない
  }
};

エラーだ。コンパイルできない。どうやら System::Object のメンバではないメソッドを呼び出すことができないようだ。このエラーを取り除くためには、次のように T が何者なのかを教えてやる必要がある。

public interface class HasFunc {
  System::String^ Func1();
  System::String^ Func2();
};

public ref class Base
{
public:
  generic <typename T> where T: HasFunc // T が何者かを教える
  virtual System::String^ Func(T in) {
      return in->Func1(); // T は HasFunc なので、Func1 を呼べる
  }
};

public ref class Derived: public Base
{
public:
  generic <typename T> // override しているので、T が HasFunc であることは既知
  virtual System::String^ Func(T in) override {
      return in->Func2(); // T は HasFunc なので、Func2 を呼べる
  }
};

ふむふむ、なるほど。先ほどは T が何者なのか分からなかったので、どんな型からも呼び出すことができる System::Object のメソッドしか受け付けなかったというわけか。今回は、T が HasFunc というインタフェースを持っていることが分かっているので、Func1 も Func2 を呼び出せる......って、当たり前じゃないか。

それなら、こんな風にしても同じ事。インタフェースを知る必要があるなら、あえて generic にしなくても書ける。

public interface class HasFunc {
  System::String^ Func1();
  System::String^ Func2();
};

public ref class Base
{
public:
  virtual System::String^ Func(HasFunc^ in) { // 無理に generic にしなくても、こうすればよいだけ
      return in->Func1(); // in は HasFunc なので、Func1 を呼び出せる
  }
};

public ref class Derived: public Base
{
public:
  virtual System::String^ Func(HasFunc^ in) override {
      return in->Func2(); // Func2 も呼び出せる
  }
};

.NET の generics は、コンパイル時にソースコードを要求しないという利点を求めた結果、多分、C++ ユーザにとって template を使う大きな理由の一つである「静的なダックタイピング」を切り捨てざるを得なかったのだろう。

これまで generic を template のようなものだと思っていたが、これではまるで別物だ。考えを改めなければならない。

教科書に載っているような Pimpl の実装は、大抵の場合、次の例の前半部分まで。こうやって隠蔽した Impl のポインタ pImpl_ を正しく扱うためには、コンストラクタ、デストラクタ、コピーコンストラクタ、代入演算子を「正しく」実装しなければならない。

class PimplTest {
public:
  // ... 外部に公開するインタフェース

private:
  class Impl; // 実装の詳細は Impl に隠蔽し、
  Impl* pImpl_; // そのポインタを保持する

// Impl を正しく扱うためには、以下のコードを「正しく」書かなければならない
public:
  PimplTest(); // ここで new
  ~PimplTest(); // ここで delete
  PimplTest(const PimplTest& obj); // Impl に対する深いコピーが必要
  PimplTest& operator = (const PimplTest& rhs); // こちらも同様に深いコピー
};

時々、ポインタ周りを楽にするために shared_ptr を使って Pimpl イディオムを実装している例を見かけるが、これではコピーや代入時に実装の詳細が共有されてしまう。コピーや代入を禁止しても構わない場合ならこれで充分かも知れないが、そうでない場合は自前のコピーコンストラクタや代入演算子を用意する必要があるため、やはり、お手軽とは言い難いだろう。

class PimplTest {
public:
  PimplTest();

// 値の読み書きを表現
public:
  void SetVal(int val);
  int GetVal() const;

// 実装の詳細
private:
  class Impl;
  std::tr1::shared_ptr<Impl> pImpl_; // コピーさえしなければ、これで間に合うが......
};

cpp 側はこんな感じ。

// 実装の詳細
class PimplTest::Impl {
  int val_;
public:
  Impl(): val_(int()) {}
  void SetVal(int val) { val_ = val; }
  int GetVal() const { return val_; }
};

// コンストラクタで new するだけなので楽チン
PimplTest::PimplTest(): pImpl_(new Impl) {}

// 委譲の嵐
void PimplTest::SetVal(int val) { pImpl_->SetVal(val); }
int PimplTest::GetVal() const { return pImpl_->GetVal(); }

このように実装してしまうと、shared_ptr が持つ「コピー時に参照先（この場合は Impl のインスタンス）を共有する」という性質から、次のような問題が生じてしまう。

// PimplTest のインスタンスに 1 と 2 をセットする
PimplTest test1, test2;
test1.SetVal(1);
test2.SetVal(2);

// 当然、1, 2 と表示される
cout << test1.GetVal() << ", " << test2.GetVal() << endl;

test1 = test2; // test2 の内容を test1 に代入（これで test1 が 2 になるはず）
test2.SetVal(20); // test2 は 20 に変更

// 2, 20 と表示されることを期待するが、
// 実際には test1 と test2 は同じ Impl を参照しているため、20, 20 と表示される
cout << test1.GetVal() << ", " << test2.GetVal() << endl;

つまり、Pimpl に適したスマートポインタは、次の2つの機能を兼ね備えていなければならないということだ。

1. 不完全型を受け付ける（クラスの先行宣言だけでコンパイル可能）
2. 値のセマンティクスを持つ（勝手に深いコピーをしてくれる）

shared_ptr は1つ目の機能を deleter によって実現しているが、残念ながら2番目の機能が期待通りではない。どこかに上記の機能を兼ね備えた Pimpl に最適なスマートポインタはないかと探し回ったが、探し方が悪いのだろう。満足のいくものを見つけることは出来なかった。そこで、勉強も兼ねて自作に踏み切ってみることにした。車輪の再発明かも知れないが、結構勉強になったので私的には大満足だ。

気に入った方は好きに使っていただいて構わないし、改変や商用利用、その他諸々何でもアリ。ただし、当然ながら無保証なのでご注意を。

この特別な Pimpl イディオム用のスマートポインタ Pimpl を使えば、先ほどのコードが次のように変化し、

class PimplTest {
public:
  PimplTest();

public:
  void SetVal(int val);
  int GetVal() const;

private:
  class Impl;
  Pimpl<Impl> pImpl_; // この部分を Pimpl に変更
};

実行結果も期待通りになる。

// PimplTest のインスタンスに 1 と 2 をセットする
PimplTest test1, test2;
test1.SetVal(1);
test2.SetVal(2);

// 当然、1, 2 と表示される
cout << test1.GetVal() << ", " << test2.GetVal() << endl;

test1 = test2; // test2 の内容を test1 に代入して、
test2.SetVal(20); // test2 は 20 に変更

// 今度は期待通り 2, 20 と表示される
cout << test1.GetVal() << ", " << test2.GetVal() << endl;

Pimpl の実装は以下の通り。これを適当な namespace に入れてインクルードガードを付ければ Pimpl.h の完成だ。結構便利に使えると思うのだが如何だろう。

// 不完全型を受け付けるためのインタフェース
// ポインタを void* で扱っている部分がミソ
class ImplHolderBase {
public:
  virtual ~ImplHolderBase() {}
  virtual ImplHolderBase* Clone() const = 0;
  virtual void CopyTo(ImplHolderBase* pHolder) const = 0;
  virtual void* GetPtr() = 0;
  virtual const void* GetPtr() const = 0;
};

// ポインタを保持するクラス
template <class T>
class ImplHolder: public ImplHolderBase {
  T* ptr_; // これが Impl の実体
public:
  explicit ImplHolder(T* ptr): ptr_(ptr) {}
  virtual ~ImplHolder() {
      delete ptr_;
  }
  virtual ImplHolderBase* Clone() const {
      return new ImplHolder(new T(*ptr_)); // ここで T のコピーコンストラクタが呼ばれる
  }
  virtual void CopyTo(ImplHolderBase* pHolder) const {
      // ImplHolder 以外は考えられないので、static_cast で変換可能
      *(static_cast<ImplHolder*>(pHolder)->ptr_) = *ptr_; // ここで T の代入演算子が呼ばれる
  }
  virtual void* GetPtr() { return ptr_; }
  virtual const void* GetPtr() const { return ptr_; }
private: // 念のためコピーと代入を禁止しておく
  ImplHolder(const ImplHolder&); // 未実装
  ImplHolder& operator = (const ImplHolder&); // 未実装
};

// Pimpl クラスの実体
template <class T>
class Pimpl {
  ImplHolderBase* pHolder_; // T に依存しない
public:
  explicit Pimpl(T* ptr): pHolder_(new ImplHolder<T>(ptr)) {} // この時点で T の型が決まる
  ~Pimpl() {
      delete pHolder_; // T が不完全型でも問題ない
  }
  Pimpl(const Pimpl& init): pHolder_(init.pHolder_->Clone()) {} // コピーコンストラクタは Clone で対応
  Pimpl& operator = (const Pimpl& rhs) {
      rhs.pHolder_->CopyTo(pHolder_); // 代入は CopyTo で対応
      return *this;
  }
  T& operator * () { return *(static_cast<T*>(pHolder_->GetPtr())); }
  const T& operator * () const { return *(static_cast<const T*>(pHolder_->GetPtr())); }
  T* operator -> () { return &(**this); }
  const T* operator -> () const { return &(**this); }
};

ぜひ、お試しあれ！

ある自作コントロールに自作クラス MyItem の配列をプロパティとして持たせたいと思い、System::Collections::Generic::List<MyItem^>^ 型のプロパティ MyItemList を追加することにした。cli::array ではなく List を使っているのは vector っぽく使いたいためだが、この違いは本質ではない（と思う）。悲劇の始まりは次のようなコードからだ。

ref class MyItem;
ref class MyCtrl : public System::Windows::Forms::UserControl
{
// ... 色々あって、

private:
  System::Collections::Generic::List<MyItem^>^ m_itemList; // リストの実体

public:
  MyCtrl(void) {
      InitializeComponent();

      // コンストラクタで m_itemList を確保する
      m_itemList = gcnew System::Collections::Generic::List<MyItem^>;
  }

public:
  property System::Collections::Generic::List<MyItem^>^ MyItemList { // このプロパティは
      System::Collections::Generic::List<MyItem^>^ get() { // get だけしか持っていない（set は許可しない）
          return m_itemList; // 中身は自由にしても構わないが、リストそのものはコチラで管理させてくれ
      }
  }

// ... 色々あるよね
};

// リストに格納されるモノ
ref class MyItem {
public:
  property System::String^ Label; // ラベルやら
  property System::Drawing::Color ForeColor; // 色やら
  // ... その他諸々（今回は省略）
};

コンパイルは成功するし、このコントロールをフォームに貼り付けることもできる。しかも、コントロールのプロパティには「その他」の項目として MyItemList が入っているというオマケ付き。コレクションの右にあるボタンをクリックすると MyItem のコレクションエディタが起動し、MyItemList に MyItem を追加したり編集したりと、もう至れり尽くせり状態だ。

コレクションエディタ上で MyItem を追加、編集して、いざコンパイル。

「あれ？ MyItem が消えたぞ」

何回やっても結果は同じ。コンパイルさえしなければ何も問題はないのだが、それでは意味がない。

色々調べた結果、MyItemList の DesignerSerializationVisibility 属性を Content にしなければならないことが分かった（デフォルト値は Visible）。 こうすることで、MyItemList の Content、つまり「中身」を永続化可能にするというわけだ。

[DesignerSerializationVisibility(DesignerSerializationVisibility::Content)] // これが必要
property System::Collections::Generic::List<MyItem^>^ MyItemList {
  System::Collections::Generic::List<MyItem^>^ get() {
      return m_itemList;
  }
}

これで MyItemList の中身が保存されるようになったのだが、今度はコレクションの中身が空でもデザイナ上ではボールド表示、つまり「初期値と違う」と主張し始めた。MyItemList 上の右クリックで初期化しようとしても、リセット自体がグレーアウトされている。

「あぁ、確かこれは DefaultValue 属性だったな」と思ったが、今回は MyItemList を自前で管理しているため、リテラルとしての初期値が存在しない。初期値というよりは、初期化メソッドが必要なのだ。

さらに調査を進めると、こういう場合は ShouldSerialize, Reset メソッドを使えばよいことが分かった。最初は何を言っているのか良く分からなかったのだが、どうやら .NET Framework では ShouldSerializeプロパティ名 と Resetプロパティ名の2つのメソッド名を特別扱いするという仕様のようだ。

つまり、こういうこと。

// MyItemList という名前のプロパティがあれば、
// ShouldSerializeMyItemList と ResetMyItemList という2つのメソッドが特別扱いされる。
[DesignerSerializationVisibility(DesignerSerializationVisibility::Content)]
property System::Collections::Generic::List<MyItem^>^ MyItemList {
  System::Collections::Generic::List<MyItem^>^ get() {
      return m_itemList;
  }
}
// このメソッドは「永続化すべきかどうか」つまり「初期値と違うかどうか」を返す
bool ShouldSerializeMyItemList() {
  return m_itemList->Count > 0; // 空じゃなければ初期値でない
}
// 「リセット」時に呼ばれるメソッド
void ResetMyItemList() {
  m_itemList->Clear(); // 空にする
}

これで万事うまくいく...はずだった。しかし、肝心の「リセット」がグレーアウトされたままになっている。ここで悩むこと数時間。「ひょっとして、MyItemList に set がないからかも」と思い、次のように set を追加したら...動いてしまった。

[DesignerSerializationVisibility(DesignerSerializationVisibility::Content)]
property System::Collections::Generic::List<MyItem^>^ MyItemList {
  System::Collections::Generic::List<MyItem^>^ get() {
      return m_itemList;
  }
  // これがないと「リセット」が有効にならない
  void set(System::Collections::Generic::List<MyItem^>^ itemList) {
      if (!itemList) // 仕方がないので例外を投げることにした
          throw gcnew System::Exception("MyItemList must not be null.");
      m_itemList = itemList;
  }
}
bool ShouldSerializeMyItemList() {
  return m_itemList->Count > 0;
}
void ResetMyItemList() {
  m_itemList->Clear();
}

こういう仕様なのかどうかは分からないが、MyItemList に set が無いからという理由で ResetMyItemList が呼べないのは納得できない。ただでさえ const まわりが貧弱なのに、それに抵抗すると余計な労力を強いられるとは。ちなみに、現在の環境は Visual Studio 2008 SP1。次のバージョンでは何とかして欲しいところだが、今後 C++/CLI を使うかどうかは微妙なので、まぁどっちでもいいや。

class Hoge {
public:
  template <typename T>
  virtual void Func(const T& in) {} // メンバ関数テンプレートは仮想関数にできない
};

こういう場合、クラスを丸ごとテンプレート化してしまえば何とかなる場合が多いので、どうしてもという時は設計を見直すことになるだろう。こうすれば仮想関数でテンプレート引数の型が使えるようになる。

template <typename T> // テンプレートクラスにすれば、仮想関数で T が使える
class Hoge {
public:
  virtual void Func(const T& in) {}
};

A member function template shall not be virtual. [Example:
    template <class T> struct AA {
        template <class C> virtual void g(C); // error
        virtual void f(); // OK
    };
--end example]

ISO/IEC 14882:2003, 14.5.2 Member templates - 3

でも、これで終わってしまったら面白くないので、もう少し掘り下げてみよう。何故こういう仕様になったのだろうか。テンプレートクラスが仮想メンバ関数を持てるならば、仮想テンプレートメンバ関数を許してくれても良いではないか。

色々調べてみた結果、満足のいく答えは Stroustrup 氏の著書「プログラム言語 C++ 第3版」で見つけることができた。灯台下暗しとはこのことだ。

メンバテンプレートは、virtual 宣言できない。たとえば次の通り。

class Shape {
    // ...
    template<class T> virtual bool intersect(const T&) const = 0; // エラー: virtual テンプレート
};

この例は、文法から逸脱しているものとして扱わなければならない。これを認めると、仮想関数を実装するために伝統的に使われてきた仮想関数テーブルテクニック（§2.5.5）が使えなくなる。誰かが新しい引数型を指定して intersect() を呼び出すたびに、リンカは Shape クラスの仮想テーブルに新しいエントリを追加しなければならなくなってしまう。

プログラム言語 C++ 第3版, 13.6.2 メンバテンプレート

なるほど、納得。全ての翻訳単位をコンパイルしてみないと、仮想関数テーブルが一意に定まらないというわけか。

ところで、何故「仕様だから」で済むような話にここまでこだわるのか。それは C# では仮想メンバ関数にジェネリクス（template のようなもの）が使えると聞いたからだ。C++ 以外の言語はサッパリなので、これを機に少し調べてみようと思ったのだが、その前に出来ない理由を明確にしておこうと思った次第。

C# はこの問題をどうやって解決しているのだろう......と、考えているうちに、なんとなく答えが分かったような気がする。C#（に限らず .NET 系全般）なら Just In Time でコンパイルしてしまえば良いではないか。無いものは作ればいい。リンカが困ったらコンパイル。たぶん、これだな。

Blender はフリーの 3DCG ソフト。操作方法にクセがありまくるため毎回イライラしながら作ることになるのだが、icon 系の画像を作る時にはナンダカンダ言いつつも結局 Blender を使っていることが多い。

favicon 程度の画像に Blender を使うのは大げさな感じがするかも知れないが、むしろ、基本的な機能だけで間に合ってしまう favicon だからこそ、全くの素人でもそれなりの画像が得られるとも言える。Blender を使えば絵の上手い下手は関係ない。物体を3次元で表現できれば、後は写真を撮る要領でイメージを切り取ってやるだけだ。

ところで、今回 favicon の画像に薬のカプセルを選んだのは、「zakio.net が悩めるエンジニアの処方箋になってくれれば」という強い思いがあった訳ではない。単にモデリングが簡単だったからだ。16 x 16 pixel では複雑なモデルを表現しきれないので、カプセル程度の単純なものの方が favicon には適していると思う。

一応、カプセルの表面に zakio.net とプリントしてはみたが、16 x 16 の favicon では、そんな細部のこだわりは全くの無意味。本物のカプセルを参考にして微妙なくぼみを付けてみたりもしたが、その部分に至っては拡大してもこの有様だ。3DCG でリアリティを出すためには細部にこだわると良いらしいが、favicon でリアリティを追求する必要はこれっぽっちもない。ここまでくると単なる自己満足の世界である。

CLI は値型と参照型を区別する。一般に値型はスタック、参照型はヒープ上に配置されるが、C++/CLI では参照型であっても C++ と同じようにスタックに置くことができる。正確には「置いたように見せかける」だが、構文的にも意味的にもスタックに置いたオブジェクトと同じように扱える。

List<int> list1; // 参照型なのにスタックに置ける（ように見える）
List<int>* list2 = &list1; // コンパイルエラー: CLI heap 上にあるオブジェクトはポインタで参照できない
List<int>& list3 = list1; // コンパイルエラー: CLI heap 上にあるオブジェクトはトラッキング参照を用いること
List<int>^ list4 = %list1; // % でハンドルを取得
List<int>% list5 = list1; // トラッキング参照は & と同様の振る舞い

構文としてはスタックだが、参照型はあくまで参照型。実際のオブジェクトは CLI ヒープ上に存在するため、間接的に参照する場合はポインタではなくハンドルを使うことになる。つまり * → ^, & → % のルールで自然に振舞うということ。ここまでは問題ない。混乱の元は値型だ。

using namespace System::Drawing;

Point pt1; // 値型をスタックに置く
Point* pt2 = &pt1; // 値型は CLI heap 上にないので、ポインタで参照できる
Point& pt3 = pt1; // & も利用可
Point^ pt4 = %pt1; // コンパイルエラーにならない！
Point% pt5 = pt1; // コンパイルエラーにならない！

ハンドルでは扱えないはずだ......ったが、コンパイルエラーにはならない。どうやらこれがボックス化というもののようだ。ボックス化とは、値型のインスタンスをハンドルで扱うために、インスタンスを一旦 CLI ヒープに「暗黙に」コピーし、そのコピー先を指し示すというものだ。そんな無茶な。

それでは値を間接的に指し示すもの、ポインタとしての役割を果たしていないではないか。ボックス化によって得られたハンドルは、もはや、元のオブジェクトとは無縁の存在というわけだ。実験してみよう。

Point pt(0, 0); // 値型をスタック上に置く
Point* pPt = &pt; // ポインタで参照する
Point^ hPt = %pt; // ハンドルで参照するとボックス化される
pPt->X = 1; // ポインタ経由で X を 1 にする
hPt->Y = 2; // ハンドル経由で Y を 2 にする

cout << "pPt = (" << pPt->X << ", " << pPt->Y << ")\n";
cout << "hPt = (" << hPt->X << ", " << hPt->Y << ")\n";

// [出力結果]
// pPt = (1, 0)
// hPt = (0, 2)

確かに思ったとおりに動作している。駄目だ、ついていけない。Java とか C# とか、平気でボックス化とか言ってる言語で、この手の失敗をしないという自信が持てない。

しかも、こんな書き方もできるらしい。

Point pt; // 値型をスタックに置く
Point^ hPt = pt; // いきなりハンドルで受ける！！

C++ 的な目線で見ると、これは Point* pPt = pt; という風に見えるが、ボックス化様にそんな古い常識は通用しない。何でもアリだ。

ん、ひょっとして、new で native heap に確保したオブジェクトもボックス化様は受け入れてくれるのではないか？

Point* pPt = new Point; // 値型を native heap に置く
Point^ hPt = *pPt; // Point^ hPt = pt; が OK なら、これだって OK だ
delete pPt;

通ったぁ！ ボックス化様、万歳。...もうシラネ。

まとめ

• C++/CLI では値型にも参照型にもスタックの構文が使える
• スタックに置いた参照型を参照する場合は * や & ではなく ^ や % を使う
• スタックに置いた値型を参照する場合は *, &, ^, % の全てを使うことができる
• スタックや native heap 上のオブジェクトを ^ や % で参照すると、ボックス化によるコピーを参照するようになる

まずは単純な話から。

using namespace std;
using namespace System::Collections::Generic;

vector<int>* pVec = new vector<int>; // native heap を new で確保して pointer で受ける
List<int>^ hList = gcnew List<int>; // CLI heap を gcnew で確保して handle で受ける

// -> は同じ
pVec->push_back(1);
hList->Add(1);

// * も同じ
(*pVec).push_back(2);
(*hList).Add(2);

// delete も同じ
delete pVec;
delete hList;

vector に対応するものが List という点が気持ち悪いが、まぁこれはそういうもの。大事なのは new → gcnew, * → ^ という対応の部分だ。一旦領域を確保してしまえば、後は C++ と同じように扱える。

vector<int>& rVec = *pVec;
List<int>% tList = *hList;

cout << "rVec = " << rVec[0] << ", " << rVec[1] << endl;
cout << "tList = " << tList[0] << ", " << tList[1] << endl;

ここまでは簡単だ。CLI heap を扱う場合は new の代わりに gcnew、* や & の代わりに ^ や % を使えば、C++ と同じようにポインタや参照を扱うことが出来る。

ところで、C++ では実体からポインタを得る場合にも & が用いられる。CLI heap 上の実体からハンドルを得る場合も、先ほどと同様に & を % に置き換えればよい。

vector<int>* pVec2 = &rVec; // C++ では & でポインタが得られる
List<int>^ hList2 = %tList; // これに相当する演算子もやはり %

cout << (pVec == pVec2) << endl; // pVec と pVec2 は同じものを指す
cout << (hList == hList2) << endl; // hList と hList2 も同じものを指す

これはこれで納得できるような気もするが、参照はがしの時は (*hList).Add(2); のようにハンドルに対して ^ ではなく * を使っていたではないか。それに合わせるなら実体からハンドルを得る場合も % ではなく & だと思うし、* → ^, & → % という対比を重視するならハンドルの参照はがしの方を * ではなく ^ にすべきだと思う。こういうズレが混乱を招くような気がするのだが、あまりそういった話を聞かないのは何故だろう。

vector<int>& rVec = *pVec;
List<int>% tList = *hList; // こうやって並べるとココの * が気になってくる
vector<int>* pVec2 = &rVec;
List<int>^ hList2 = %tList;

vector<int>& rVec = *pVec;
List<int>% tList = ^hList; // * に対応する ^ で参照を剥がすか、
vector<int>* pVec2 = &rVec;
List<int>^ hList2 = %tList;

vector<int>& rVec = *pVec;
List<int>% tList = *hList;
vector<int>* pVec2 = &rVec;
List<int>^ hList2 = &tList; // & でハンドルを得てくれればスッキリしたのに......

まぁ、文句を言っても仕方がないので、これはこういうもんだと思うしかない。

次に、こんな関数を用意してみた。

void Func1(vector<int>** ppVec) {
  *ppVec = new vector<int>(10);
}

void Func2(List<int>^^ hhList) {
  *hhList = gcnew List<int>(10);
}

Func1 はポインタそのものを書き換えるために、ポインタへのポインタを引数としている。Func2 は Func1 の * を ^ に置き換えたもの。* → ^ というルールで全てうまくいくなら Func2 も問題ないはずだが、残念ながらこれはコンパイルエラーとなってしまう。

error C3699: '^' : cannot use this indirection on type 'System::Collections::Generic::List ^'

C++/CLI の仕様書にはそれらしい記述が見当たらなかったので、これが言語的に禁止されているかどうかは不明。ただ、ハンドルのハンドルを許してしまうと、ハンドルのハンドルのハンドルのハンドルの......ハンドルも合法となり、ガベージコレクションの時に悲惨なことになりそうな気はする。理由はともかく、C3699 の説明には「^^ の代わりに ^% を使え」とあるので、コンパイルを通したければそれに従うしかない。^% は C++ 的には *& に相当するので、これは「ハンドルそのものを参照渡ししなさい」という意味だ。「そりゃぁそうなんだけど･･････」と、モヤモヤしたまま書き直した以下のコードは（当然ながら）コンパイル可能。

void Func1(vector<int>*& pVec) {
  pVec = new vector<int>(10);
}

void Func2(List<int>^% hList) {
  hList = gcnew List<int>(10);
}

ハンドルやトラッキング参照にスタック構文が加わると話がもう少しややこしくなるのだが、長くなってきたので別の機会に。

まとめ

• CLI heap は new ではなく gcnew で確保し、* ではなく ^（ハンドル）で受ける
• CLI heap 用の参照は & ではなく %（トラッキング参照, 追跡参照）
• ポインタもハンドルも参照はがしは * だが、トラッキング参照からハンドルを得る場合は & ではなく %
• ^^（ハンドルのハンドル）は不可

参考文献

• C++/CLI Language Specification, Standard ECMA-372

気になったことを備忘録の感覚で書き留めていこうという趣旨で blog を始めたのだが、気になることの大半がソフトウェアに関する事なので、ソースコードを簡単にコピペできることは「めんどくさくない」運用という点においては必須の機能。

とりあえずは、以下のようなコードが普通にコピペできれば合格だ。

template <typename T>
class Hoge {
    T m_val;
public:
    explicit Hoge(const T& val = T()): m_val(val) {}
    const T& GetVal() const {
        return m_val; // 持ってる値を返すだけ。意味も無くコメントを書いているのは、一行を無理やり長くするためだったりする。
    }
};

SyntaxHighlighter

検索で真っ先にヒットしたのが SyntaxHighlighter というもの。見た感じ良さそげなので試してみようとしたのだが、Java Script で書かれているという点に引っかかってしまった。NoScript を愛用している私が、ブログツールやコメントの類ならともかく、自分の blog のエントリー部分で Java Script に頼ってしまうのは何ともいえない矛盾を感じる。Java Script を OFF にしていればシンタックスハイライト無しの pre タグとして見えるような気がするので、もしそうなら許容範囲に収まっているかも知れないが、とりあえず保留。

VimColor

次に見つかったのが VimColor プラグインというもの。これは Movable Type 用のプラグインなので、サーバ側で整形処理が完結する。よし、これだ。

template <typename T>
class Hoge {
  T m_val;
public:
  explicit Hoge(const T& val = T()): m_val(val) {}
  const T& GetVal() const {
      return m_val; // 持ってる値を返すだけ。意味も無くコメントを書いているのは、一行を無理やり長くするためだったりする。
  }
};

最初のインデントがおかしいけど、概ね良好。うん、悪くないね。

......と、簡単に導入しているように見えるが、root 権限の無いレンタルサーバ上に Perl のモジュールやら vim やら（！）をインストールするのは大変な作業だった。そもそも「CPAN って何？」状態だったし、PuTTY を使ったのも初めて。

以下、参考にしたもの。

• vimcolor プラグイン
• 一般ユーザ環境におけるCPANモジュールの使い方
• さくらインターネットの共用サーバに vim をインストールする

また、ここのコメント欄にあるように、SetEnv できない環境下で CGI からローカルモジュールを使う場合は use lib が必要。そのため、プラグインの頭の部分を以下のように修正して Text::VimColor モジュールのインストール先を指定する。

use strict;
use MT;
use MT::Template::Context;
use lib '/home/*****/perl/lib/perl5/site_perl';
use Text::VimColor;

私のように vim を自前でインストールした場合は、Text::VimColor にもその場所を教えてあげないといけない。

my $vimcolor = Text::VimColor->new(vim_command => '/home/*****/local/bin/vim', vim_options => \@options);

また、そのままだとエラーになるので、options に -T xterm を追加する。この問題の解決には Text::VimColor in a CGI - possible? が役立った。ついでに、さりげなく tabstop を 4 にしている。

my @options = (qw( -XZ -i NONE -u NONE -N -T xterm ),
  '+set nomodeline',
  '+set expandtab',
  '+set tabstop=4',
  '+set encoding=' . MT::ConfigMgr->instance()->PublishCharset);

ちなみに、MTEntryBody だけでなく MTEntryMore の方にも vim_color = "none" としておかないと、「続き」側で編集した内容に VimColor が適用されない。まぁ、このあたりは特に何も書かなくても気づくとは思うが、念のため。

<$MTEntryMore vim_color="none"$>

それにしても、プラグインの導入記事にプラグイン自身が活躍するところが面白い。いい感じに続けられそうな気がするぞ。

こんなイイ加減なエントリーで始まるブログも珍しいと思うが、極度に飽きっぽい私にとっては、これくらいから始めた方が長続きするはず。

最近（に限った話ではないかも知れないが）物忘れが激しくなってきた気がするので、気になったことは記録しておいた方がいいかも、というのがブログを始めようと思った動機。ただし、記録という作業そのものに手間がかかってしまうとあっという間に終了フラグが立ってしまう。

そこで、ブログ界のデファクトスタンダードである（らしい） Movable Type を導入し、このあたりの「めんどくささ」を取り除いてみようという試みだが、果たしてうまくいくことやら......。