cpp_interface.dd

Ddoc

$(SPEC_S C++とのインターフェイス,

	$(P
	D は
	$(DDLINK interfaceToC, Interfacing to C, Cとのインターフェイス),
	は完璧ですが、C++ とのインターフェイスはかなり制限されています。
	C++ とリンクするには３つの方法があります:
	)

	$(OL

	$(LI C++側の、C向けインターフェイスを作る機能を用いる。
	そして、D側からは
	$(DDLINK interfaceToC, Interfacing to C, Cとのインターフェイス)
	でアクセス。
	)

	$(LI C++側の、COMインターフェイスを作る機能を用いる。
	そして、D側からは
	$(DPLLINK COM.html, COMインターフェイス)
	を通じてアクセス。
	)

	$(LI 以下で述べるような、
	制限付きでC++の関数およびクラスに直接アクセスするための機能を用いる。
	)

	)

<h2>基本的な考え方</h2>

	$(P C++ との 100% の互換性を達成するということは、
	完全なC++コンパイラのフロントエンドをDに実装するというのと大差ありません。
	過去の経験からすると、
	その実装は最低でも10人年規模のプロジェクトになってしまい、
	Dコンパイラを実装するのが事実上不可能になってしまいます。
	C++ とのリンクを実現しようとしている他の言語も同じ問題を抱えていて、
	いくつかの対案が考えられています:
	)

	$(OL
	$(LI COM インターフェイスをサポートする (ただしWindows専用))
	$(LI C++
	のコードを頑張って手作業でCでラップする)
	$(LI SWIG のような、
	C ラッパを生成する自動化ツールを使う)
	$(LI C++のコードを全部他の言語に移植する)
	$(LI あきらめる)
	)

	$(P D では現実的なアプローチとして、
	全てではないにしろかなり多くの問題を解決できるような、
	以下にあげるささやかな機能を提供しています：
	)

	$(UL
	$(LI C++ と名前マングリング規則を合わせる)
	$(LI C++ と関数呼び出し規約を合わせる)
	$(LI C++ と、単一継承の場合に限り仮想関数テーブルの形式を合わせる)
	)

<h2>C++ のグローバル関数を D から呼ぶ</h2>

	$(P C++のソースファイルに書かれたC++の関数があったとします:)

$(CPPCODE
#include &lt;iostream&gt;

using namespace std;

int foo(int i, int j, int k) {
  cout &lt;&lt; "i = " &lt;&lt; i &lt;&lt; endl;
  cout &lt;&lt; "j = " &lt;&lt; j &lt;&lt; endl;
  cout &lt;&lt; "k = " &lt;&lt; k &lt;&lt; endl;

  return 7;
}
)

	$(P これを呼び出したいDのコードでは、$(CODE foo)
	を C++ のリンケージと関数呼び出し規約に従うものとして宣言します:
	)

------
extern (C++) int foo(int i, int j, int k);
------

	$(P こうすると、Dのコードから呼び出すことが可能になります:)

------
extern (C++) int foo(int i, int j, int k);

void main() {
  foo(1,2,3);
}
------

	$(P 最初のファイルをC++コンパイラで、2つめをDコンパイラでコンパイルして、
	両者をリンクして実行すると、
	以下の結果が得られます:)

$(CONSOLE
i = 1
j = 2
k = 3
)

	$(P 何が起きているのかをもっと具体的に説明しますと:)

	$(UL 
	$(LI Dコンパイラは、C++ の関数名がどのようにmangleされているのか、
		またC++の関数の正しい呼び出し/復帰手続きについて、把握しています。)

	$(LI C++ にはモジュールという概念がないため、
		C++ リンケージを持つ関数はプログラム全体でグローバルなものとして扱われます。)

	$(LI Dでは、__cdecl, __far, __stdcall, __declspec,
		などC++標準外の拡張呼び出し規約はサポートされません)

	$(LI 型修飾子 volatile は D にはありません。)

	$(LI Dの文字列は0終端になっていません。
		詳しくは "データ型の互換性" をご覧下さい。
		ただし、文字列リテラルは0終端になっています。)

	)

	$(P 名前空間の中にある C++ 
	の関数は、直接 D から呼び出すことができません。
	)


<h2>D のグローバル関数を C++ から呼ぶ</h2>

	$(P D の関数を C++ からアクセス可能にするには、
	C++ リンケージで宣言します:)

---
import std.stdio;

extern (C++) int foo(int i, int j, int k) {
  writefln("i = %s", i);
  writefln("j = %s", j);
  writefln("k = %s", k);
  return 1;
}

extern (C++) void bar();

void main() {
  bar();
}
---

	$(P C++ 側はこんな風になります:)

$(CPPCODE
int foo(int i, int j, int k);

void bar() {
  foo(6, 7, 8);
}
)

	$(P コンパイル、リンクして実行すると以下の出力が得られます:)

$(CONSOLE
i = 6
j = 7
k = 8
)


<h2>クラス</h2>

	$(P D のクラスは常に Object から派生していて、
	また、C++ のクラスのレイアウトと互換性がありません。
	しかし、D の interface は、
	C++ の単一継承のクラス階層と非常によく似ています。
	そこで、$(CODE extern (C++)) 属性付きで宣言された D の interface は、
	仮想関数テーブル (vtbl[]) の形式を
	完全に C++ と合わせるようにしました。
	通常の D の interface は、vtbl[] の先頭に
	D の RTTI 情報へのポインタが入るという少し違った形式となっています
	（C++ の場合、
	先頭には一つめの仮想関数へのポインタが格納されます）。
	)

<h2>C++ の仮想関数を D から呼ぶ</h2>

	$(P 以下のようにクラスを定義しているC++のソースがあったとします:)

$(CPPCODE
#include &lt;iostream&gt;

using namespace std;

class D {
 public:
  virtual int bar(int i, int j, int k)
  {
    cout &lt;&lt; "i = " &lt;&lt; i &lt;&lt; endl;
    cout &lt;&lt; "j = " &lt;&lt; j &lt;&lt; endl;
    cout &lt;&lt; "k = " &lt;&lt; k &lt;&lt; endl;
    return 8;
  }
};

D *getD() {
  D *d = new D();
  return d;
}
)

	$(P D のコードでこれを扱うには:)

---
extern (C++) {
  interface D {
    int bar(int i, int j, int k);
  }

  D getD();
}

void main() {
  D d = getD();
  d.bar(9,10,11);
}
---

<h2>D の仮想関数をC++から呼ぶ</h2>

	$(P D のコード:)

---
extern (C++) int callE(E);

extern (C++) interface E {
  int bar(int i, int j, int k);
}

class F : E {
  extern (C++) int bar(int i, int j, int k)
  {
    writefln("i = ", i);
    writefln("j = ", j);
    writefln("k = ", k);
    return 8;
  }
}

void main() {
  F f = new F();
  callE(f);
}
---

	$(P に C++ コードからアクセスするには:)

$(CPPCODE
class E {
 public:
  virtual int bar(int i, int j, int k);
};


int callE(E *e) {
  return e->bar(11,12,13);
}
)

	$(P 注:)

	$(UL
	$(LI 非 virtual 関数と
	static メンバ関数にはアクセスできません。)

	$(LI クラスのフィールドには、getter/setter
		を仮想関数で用意することでしかアクセスできません。)
	)

<h2>関数オーバーロード</h2>

	$(P C++ と D では関数オーバーロードの規則が異なっています。
	D のソースコードでは、たとえ $(CODE extern (C++)) な関数であっても、
	D のオーバーロード規則に従います。
	)


<h2>メモリ割り当て</h2>

	$(P C++ では、
	$(CODE ::operator new()) や $(CODE ::operator delete()) によって明示的にメモリを管理します。
	一方 D ではガベージコレクタでメモリを割り当てるので、
	明示的な delete は不要です。
	D の new と delete は C++ の
	$(CODE ::operator new) や $(CODE::operator delete) と互換性がありません。
	C++ の $(CODE ::operator new) で割り当てたメモリを
	D の $(CODE delete) で解放しようとしたり、あるいはその逆をやろうとすると、
	悲惨なことになってしまうでしょう。
	)

	$(P mallocで確保されたバッファを要求するようなC++の関数と連携するために、
	D では c.stdlib.malloc() や c.stdlib.free() の呼び出しによって
	明示的にメモリ管理を行うこともできます。
	)

	$(P Dのガベージコレクタで確保したメモリへのポインタを渡すには、
	C++の関数がそのメモリを使い終わる前にガベージコレクタが領域を回収してしまう、
	といった事故が起きないことを確かめなくてはなりません。
	これは幾つかの方法で実現できます：
	)

	$(UL 

	$(LI std.c.stdlib.malloc() で確保した領域にデータをコピーし、
		そちらを代わりに渡す。)

	$(LI その領域へのポインタをスタック上（引数か、自動変数）に残しておく。
		ガベージコレクタはスタック上のオブジェクトは生きていると判定します。)

	$(LI Lその領域へのポインタを静的データ領域に残しておく。
		ガベージコレクタは静的データ領域のオブジェクトは生きていると判定します。)

	$(LI そのポインタを、std.gc.addRoot() か std.gc.addRange()
		によってガベージコレクタへ登録する。)

	)

	$(P オブジェクトがまだ使われていることを
	GC に知らせるには、
	割り当てられたメモリ領域の内部へのポインタがあれば十分です。
	領域の先頭へのポインタを保持しておく必要はありません。
	)

	$(P Dによって作られた以外のスレッドのスタックや、
	他のDLLに属するデータセグメントについては、
	ガベージコレクタによって探索されません。
	)

<h2>データ型の互換性</h2>

	$(TABLE2 D と C の対応する型,

	$(TR
	$(TH D の型)
	$(TH C の型)
	)

	$(TR
	$(TD $(B void))
	$(TD $(B void))
	)

	$(TR
	$(TD $(B byte))
	$(TD $(B signed char))
	)

	$(TR
	$(TD $(B ubyte))
	$(TD $(B unsigned char))
	)

	$(TR
	$(TD $(B char))
	$(TD $(B char) (char は D では unsigned))
	)

	$(TR
	$(TD $(B wchar))
	$(TD $(B wchar_t) (sizeof(wchar_t) が 2 のとき))
	)

	$(TR
	$(TD $(B dchar))
	$(TD $(B wchar_t) (sizeof(wchar_t) が 4 のとき))
	)

	$(TR
	$(TD $(B short))
	$(TD $(B short))
	)

	$(TR
	$(TD $(B ushort))
	$(TD $(B unsigned short))
	)

	$(TR
	$(TD $(B int))
	$(TD $(B int))
	)

	$(TR
	$(TD $(B uint))
	$(TD $(B unsigned))
	)

	$(TR
	$(TD $(B long))
	$(TD $(B long long))
	)

	$(TR
	$(TD $(B ulong))
	$(TD $(B unsigned long long))
	)

	$(TR
	$(TD $(B float))
	$(TD $(B float))
	)

	$(TR
	$(TD $(B double))
	$(TD $(B double))
	)

	$(TR
	$(TD $(B real))
	$(TD $(B long double))
	)

	$(TR
	$(TD $(B ifloat))
	$(TD なし)
	)

	$(TR
	$(TD $(B idouble))
	$(TD なし)
	)

	$(TR
	$(TD $(B ireal))
	$(TD なし)
	)

	$(TR
	$(TD $(B cfloat))
	$(TD なし)
	)

	$(TR
	$(TD $(B cdouble))
	$(TD なし)
	)

	$(TR
	$(TD $(B creal))
	$(TD なし)
	)

	$(TR
	$(TD $(B struct))
	$(TD $(B struct))
	)

	$(TR
	$(TD $(B union))
	$(TD $(B union))
	)

	$(TR
	$(TD $(B enum))
	$(TD $(B enum))
	)

	$(TR
	$(TD $(B class))
	$(TD なし)
	)

	$(TR
	$(TD $(I type)$(B *))
	$(TD $(I type) $(B *))
	)

	$(TR
	$(TD なし)
	$(TD $(I type) $(B &amp;))
	)

	$(TR
	$(TD $(I type)$(B [)$(I dim)$(B ]))
	$(TD $(I type)$(B [)$(I dim)$(B ]))
	)

	$(TR
	$(TD $(I type)$(B [)$(I dim)$(B ]*))
	$(TD $(I type)$(B (*)[)$(I dim)$(B ]))
	)

	$(TR
	$(TD $(I type)$(B []))
	$(TD なし)
	)

	$(TR
	$(TD $(I type)$(B [)$(I type)$(B ]))
	$(TD なし)
	)

	$(TR
	$(TD $(I type) $(B function)$(B $(LPAREN))$(I parameters)$(B $(RPAREN)))
	$(TD $(I type)$(B (*))$(B $(LPAREN))$(I parameters)$(B $(RPAREN)))
	)

	$(TR
	$(TD $(I type) $(B delegate)$(B $(LPAREN))$(I parameters)$(B $(RPAREN)))
	$(TD なし)
	)

	)

	$(P これらの対応関係は、ほとんどの 32 bit C++ コンパイラで成立します。
	ただし、
	C++標準ではそれぞれの型のサイズを明確に定めているわけではないので、注意が必要です。
	)

<h2>構造体と共用体</h2>

	$(P Dの構造体と共用体は、Cのそれとほぼ同じです。
	)

	$(P Cのコードでは、実装特有の#pragmaやコンパイラのコマンドスイッチによって、
	構造体の整列を制御します。これに対応するものとして、D には
	明示的なアラインメント属性が用意されています。
	C側でのアラインメントを調べて、
	D側の構造体宣言に明示的にその値を設定して下さい。
	)

	$(P Dはビットフィールドをサポートしません。必要ならば、
	シフトとビットマスク演算によってエミュレートできます。
	$(DPLLINK htod.html, htod) 使うと、
	ビットフィールドはシフトとマスクを使ったインライン関数に変換されます。
	)

<h2>オブジェクトの生成と破棄</h2>

	$(P メモリ割り当てと解放と同じく、
	D のコードで構築されたオブジェクトは、D のコードで破棄される必要があります。
	同様に、
	C++ で構築されたオブジェクトは C++ で破棄する必要があります。
	)

<h2>特殊なメンバ関数</h2>

	$(PD から C++ の特殊なメンバ関数を呼ぶことはできません。逆も不可能です。
	"特殊なメンバ関数"とは、コンストラクタ、デストラクタ、キャスト演算子、
	演算子オーバーロード、アロケータのことです。
	)

<h2>実行時型識別 (RTTI)</h2>

	$(P D の実行時型識別は、
	C++とは完全に違う方式で実現されています。
	この２つには互換性がありません。)

<h2>C++ クラスオブジェクトの値渡し</h2>

	$(P D から POD (Plain Old Data) な C++ の構造体にアクセスすることは可能で、
	また、参照経由で C++ のクラスの仮想関数にアクセスすることも可能です。
	しかし、C++ のクラスに値としてアクセスすることはできません。
	)

<h2>C++ テンプレート</h2>

	$(P C++ のテンプレートと D のテンプレートの共通点はほとんどありません。
	また、C++
	のテンプレートを
	Dとのリンク互換性がある形で表現するうまい方法も見あたりません。
	)

	$(P このため、C++ の STL や Boost
	が D から直接アクセスできるようになることは将来的にもおそらくないでしょう。
	)

<h2>例外処理</h2>

	$(P D と C++ の例外処理は完全に異なる物になっています。
	このため、D と C++ の境界を越えるように例外を投げるコードは、
	正しく動作しないと思われます。
	)

<h2>将来の方向性</h2>

	$(P 次期C++標準規格 C++0x がこの機能に影響するかどうかは、
	さだかではありません。)

	$(P 将来的には、C++ ABI のより多くの側面が
	Dから直接アクセス可能になる予定です。)

)

Macros:
	TITLE=C++とのインターフェイス
	WIKI=InterfaceToCPP


	CATEGORY_SPEC=$0