このままでは、新人君に「先輩、ここの static_cast にはどのような効果があるのですか？」と聞かれても、「あ、それ？ なんとなく、コンパイラが文句言ってたし」としか答えられないし、先輩に「ここで static_cast はないだろう」と言われても「あ、はい、そうですね。コンパイルエラー出ちゃったんでなんとなく付けちゃいました」となんとも間抜けな回答しかできないことになる。このままではマズイ。

前置きが長くなってしまったが、要は「static_cast について自分なりにまとめましたよ」という話だ。

The result of the expression static_cast<T>(v) is the result of converting the expression v to type T. If T is a reference type, the result is an lvalue; otherwise, the result is an rvalue. Types shall not be defined in a static_cast. The static_cast operator shall not cast away constness (5.2.11).

static_cast<T>(v) と書くと、v を T 型に変換した結果が得られる。T が参照型なら結果は lvalue, そうじゃないなら rvalue だ。static_cast 内で型を定義するのはダメ。あと、const は外せないよ。

ISO IEC 14882-2003, 5.2.9 Static cast - 1

ここでは static_cast が型を変換するという事と、const を外せない事を言っている。まだまだ序の口。

An expression e can be explicitly converted to a type T using a static_cast of the form static_cast<T>(e) if the declaration "T t(e);" is well-formed, for some invented temporary variable t (8.5). The effect of such an explicit conversion is the same as performing the declaration and initialization and then using the temporary variable as the result of the conversion. The result is an lvalue if T is a reference type (8.3.2), and an rvalue otherwise. The expression e is used as an lvalue if and only if the initialization uses it as an lvalue.

もし、T t(e) と書けるなら、static_cast<T>(e) は合法だ。static_cast の結果、t に相当する一時オブジェクト（T が参照型なら lvalue, それ以外なら rvalue）が作られるからね。一時オブジェクトの生成時に e が lvalue として扱われることもあるけど、まぁそれはコンストラクタ次第かな。

ISO IEC 14882-2003, 5.2.9 Static cast - 2

ちょっと端折りすぎかも知れないが、ここでは static_cast がコンストラクタを呼ぶことと等価であると言っている......と思う。コンストラクタで構築できるものは static_cast でも変換可能。これもまぁ、当たり前っちゃぁ当たり前。

Otherwise, the static_cast shall perform one of the conversions listed below. No other conversion shall be performed explicitly using a static_cast.

それ以外の場合、static_cast は以下の変換を行うよ。static_cast の機能はこれだけだからね。

ISO IEC 14882-2003, 5.2.9 Static cast - 3

よし、ココからが本番だ。

Any expression can be explicitly converted to type "cv void." The expression value is discarded. [Note: however, if the value is in a temporary variable (12.2), the destructor for that variable is not executed until the usual time, and the value of the variable is preserved for the purpose of executing the destructor. ] The lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) standard conversions are not applied to the expression.

どんな型でも void にできる。もちろん、値は無くなっちゃうけどね。（あ、無くなっちゃうとは言っても、一時オブジェクトのデストラクタが呼ばれるのは通常のタイミングと同じ。つまり一時オブジェクトの寿命が尽きた時なので注意。）
あと、ここでは lvalue-to-rvalue, array-to-pointer, function-to-pointer の標準変換は適用されないよ。

ISO IEC 14882-2003, 5.2.9 Static cast - 4

つまりは、static_cast<void>(何でもOK) は合法ということ。これ自体の使い道は思いつかないが（template がらみで役立つかも？）、こういう重箱の隅までキッチリ書かれているところなどは、まさに規格書といったところか。

An lvalue of type "cv1 B", where B is a class type, can be cast to type "reference to cv2 D", where D is a class derived (clause 10) from B, if a valid standard conversion from "pointer to D" to "pointer to B" exists (4.10), cv2 is the same cv-qualification as, or greater cv-qualification than, cv1, and B is not a virtual base class of D. The result is an lvalue of type "cv2 D." If the lvalue of type "cv1 B" is actually a sub-object of an object of type D, the lvalue refers to the enclosing object of type D. Otherwise, the result of the cast is undefined.
[Example:
   struct B {};
   struct D : public B {};
   D d;
   B &br = d;
   static_cast<D&>(br); // produces lvalue to the original d object
-end example]

クラス B から派生したクラス D があった時、D* を B* に変換できるなら、static_cast は B 型の lvalue を D への参照型に変換できる。ただし、B が仮想基底クラスでない場合に限るよ。もちろん、B が本当に D を指していないなら結果は未定義だからね。
（cv については自明なのであえて省略。）

ISO IEC 14882-2003, 5.2.9 Static cast - 5

ここは1つのポイント。親子関係にあるクラス間の変換を説明しているが、アップキャストではなくダウンキャストについて述べている点に注意しよう。つまり、ここでは static_cast によって安全でないダウンキャストが可能であると言っている。

これで、先ほどの「ここで static_cast はないだろう」という先輩に対して、「いや、ここは確実に D を指していることが分かっているので、dynamic_cast よりも効率の良い static_cast を使っているわけですよ」と反論できるようになった。（その後、そもそも D と分かっているという事は云々......といった感じで議論が続くと思われるが、static_cast の範疇を越えるのでこれ以上は言及しない。）

The inverse of any standard conversion sequence (clause 4), other than the lvalue-to-rvalue (4.1), array-to-pointer
(4.2), function-to-pointer (4.3), and boolean (4.12) conversions, can be performed explicitly using static_cast. The lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) conversions are applied to the operand. Such a static_cast is subject to the restriction that the explicit conversion does not cast away constness (5.2.11), and the following additional rules for specific cases:

lvalue-to-rvalue, array-to-pointer, function-to-pointer, boolean conversion 以外の標準変換は、static_cast で逆変換できる。この時の static_cast は const を外せないこと以外に以下の特別ルールが適用される。

ISO IEC 14882-2003, 5.2.9 Static cast - 6

標準変換については4章でがっつり述べられているが、整数の格上げやら浮動小数と整数の変換やら、警告が出そうな変換の類がこれに相当する。ここで重要なのは「逆変換」という部分。私が多用するのは「暗黙の変換によって値が範囲外になってしまうかもよ」とか「signed と unsigned が食い違っているよ」といった警告に対して「はい、分かってやってるんで」と意思表示をするための static_cast だが、ここで述べられているのは、4章の標準変換に含まれていない逆変換も static_cast によって可能になるという話なので、警告除けとは別次元の話。
つまり、逆向きが許されていない標準変換（つまり逆変換がエラーとなる変換）であっても、static_cast を使えば逆変換が可能になるという話だ。

どうやらこの辺りを理解すれば「警告除け」と「必然的な static_cast」の違いについて後輩に説明できるようになりそうな気がしてきた。はやる気持ちを抑え、とりあえず、以降の特別ルールについて見ていくことにしよう。

A value of integral or enumeration type can be explicitly converted to an enumeration type. The value is unchanged if the original value is within the range of the enumeration values (7.2). Otherwise, the resulting enumeration value is unspecified.

整数や enum は enum に変換できる。当然だけど enum の範囲外の値を enum に cast すると、変換後の値は不定になるよ。

ISO IEC 14882-2003, 5.2.9 Static cast - 7

これは逆向きが許されていない標準変換、enum → int に関する特別ルール。static_cast を使えば enum → int の逆向きである int → enum が可能になるが、enum の範囲外の値を enum に変換すると不定になるという（当たり前の）特別ルールを設けている。

An rvalue of type "pointer to cv1 B", where B is a class type, can be converted to an rvalue of type "pointer to cv2 D", where D is a class derived (clause 10) from B, if a valid standard conversion from "pointer to D"to "pointer to B" exists (4.10), cv2 is the same cv-qualification as, or greater cv-qualification than, cv1, and B is not a virtual base class of D. The null pointer value (4.10) is converted to the null pointer value of the destination type. If the rvalue of type "pointer to cv1 B" points to a B that is actually a sub-object of an object of type D, the resulting pointer points to the enclosing object of type D. Otherwise, the result of the cast is undefined.

クラス B から派生したクラス D があって、D* を B* に変換できる（アップキャストが許されている）なら、static_cast で B* を D* に変換できる（ただし、B が仮想基底クラスの場合を除く）。この時、null ポインタは null ポインタに変換されることが保証されているからね。あと、何度も言うようだけど、B へのポインタが実は D を指していないのに static_cast で D* に変換してしまうと、何が起こってもおかしくないから注意してね。

ISO IEC 14882-2003, 5.2.9 Static cast - 8

これは逆向きが許されていない標準変換、アップキャストに関する特別ルール。アップキャストの逆変換であるダウンキャストもまた static_cast で可能となるが、仮想基底クラスからのダウンキャストは無理な点と、dynamic_cast で失敗するようなケースで使うと未定義となることが述べられている。

ところで、「D* を B* に変換できる（アップキャストが許されている）なら」とわざわざ述べているが、そうならない場合とはどんな場合なのだろう。これは public でない継承を考えれば納得できる。例えば以下の通り。

class B {
};

class D: private B {
};

void Test()
{
  D d;
  B* pb = &d; // エラー！ D* から B* への変換は許されていない
}

アップキャストできないという事は、ダウンキャストの対象となるポインタそのものが得られないという事なので、この場合にダウンキャストできないというのは容易に理解できるだろう。

An rvalue of type "pointer to member of D of type cv1 T" can be converted to an rvalue of type "pointer to member of B of type cv2 T", where B is a base class (clause 10) of D, if a valid standard conversion from "pointer to member of B of type T" to "pointer to member of D of type T" exists (4.11), and cv2 is the same cv-qualification as, or greater cv-qualification than, cv1.63) The null member pointer value (4.11) is converted to the null member pointer value of the destination type. If class B contains the original member, or is a base or derived class of the class containing the original member, the resulting pointer to member points to the original member. Otherwise, the result of the cast is undefined. [Note: although class B need not contain the original member, the dynamic type of the object on which the pointer to member is dereferenced must contain the original member; see 5.5. ]

static_cast を使えば D のメンバへのポインタを B のメンバへのポインタに変換できる。クラスの関係や逆変換が存在することといった条件や、null ポインタ云々、変換先が存在しない場合に未定義となる点は全てクラスの場合と同じ。

ISO IEC 14882-2003, 5.2.9 Static cast - 9

メンバポインタ！ これは幸いなことに（決して短くはないプログラマ人生の中で）まだ1回しか使った事がない機能だったりするのだが、言われてみれば確かにこいつもクラスへのポインタと同じような関係が成り立つはず。練習がてらにサンプルを作ってみたが、如何せん経験が浅いのでここで述べられている事を説明し切れているかどうかは自信なし。

class B {
public:
  virtual void Func() { std::cout << "B::Func() called" << std::endl; }
};

class D: public B {
public:
  virtual void Func() { std::cout << "D::Func() called" << std::endl; }
};

void Test()
{
  B b;
  D d;
  void (B::* mpb)() = &B::Func; // B のメンバ関数へのポインタ
  void (D::* mpd)() = &D::Func; // D のメンバ関数へのポインタ
  (b.*mpb)(); // メンバポインタを介した関数呼び出し（B::Func が呼ばれる）
  //(b.*mpd)(); // エラー! B のオブジェクトに D::* を使おうとしている
  (d.*mpb)(); // メンバポインタを介した関数呼び出し（B::Func は仮想関数なので D::Func が呼ばれる）
  (d.*mpd)(); // メンバポインタを介した関数呼び出し（D::Func が呼ばれる）

  //void (B::* dtob)() = mpd; // エラー! D::* から B::* への暗黙の変換は許されていない
  void (B::* dtob)() = static_cast<void (B::*)()>(mpd); // でも static_cast を使えば変換可能
  void (D::* btod)() = mpb; // B::* から D::* への変換は OK
  (b.*dtob)(); // B::Func が呼ばれる（これが original pointer 云々の部分で言いたいことだと思う）
  //(b.*btod)(); // エラー! B のオブジェクトに D::* を使おうとしている
  (d.*dtob)(); // D::Func が呼ばれる
  (d.*btod)(); // D::Func が呼ばれる
}

メンバポインタの場合はクラスへのポインタとは逆で、子クラスから親クラスへの変換が許されていない。これは親クラスが子クラスのメンバを持っているとは限らないからと考えると理解しやすいと思う。

An rvalue of type "pointer to cv1 void" can be converted to an rvalue of type "pointer to cv2 T," where T is an object type and cv2 is the same cv-qualification as, or greater cv-qualification than, cv1. A value of type pointer to object converted to "pointer to cv void" and back to the original pointer type will have its original value.

static_cast を使えば void* を T* に変換できる。当然だけど、その void* が元々は T* であった場合に限るよ。

ISO IEC 14882-2003, 5.2.9 Static cast - 10

これも T* → void* の逆バージョン。標準変換では許されていないが、static_cast によって変換できるようになる。

static_cast に関する C++ の仕様は以上だ。私の中で理解があいまいだったのは、標準変換の逆変換と警告除けがごっちゃになっていた部分だった。標準変換自体は static_cast は不要。コンパイラは cast によって値が失われるかも知れないよと警告しているに過ぎない。当たり前と言えば当たり前だが、コンパイラが文句を言ったら static_cast を付けるという情けない対応で何とかなっていたため、完全に思考停止状態だった。本当にエラーになるような状況でも警告と同じように static_cast を付けるだけだったので、頭の中でこれらを区別しきれていなかったというわけだ。

以上を踏まえ、これからは static_cast を「それ以外の cast」ではなく、以下のような場合に使う cast として、意識的に区別しながら使ってみようと思う。

1. 安全でないダウンキャスト用の cast
2. int → enum 用の cast
3. void* → T* 用の cast
4. 警告除けの意思表示

1は元々区別して扱っていた（し、そもそも滅多に使わない）ので、結局のところ 2, 3 と 4 を区別するようになったところが進歩したところか。まぁ、コンパイラが文句を言った後で static_cast を付けるという流れはしばらく変わらないと思うが、その時に機械的に付けるのか、それとも意味を考えながら付けるのかには大きな差がある、と信じたい。

教科書に載っているような 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); }
};

ぜひ、お試しあれ！

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 でリアリティを追求する必要はこれっぽっちもない。ここまでくると単なる自己満足の世界である。

まずは単純な話から。

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"$>

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