C関数を名前変換できないのはなぜですか？

私は最近インタビューを受けました、そして尋ねられた一つの質問はextern "C"C ++コードで何が使用されているかということでした。Cは名前のマングリングを使用しないので、C ++コードでC関数を使用することだと答えました。Cが名前のマングリングを使用しない理由を尋ねられましたが、正直に答えることができませんでした。

C ++コンパイラーが関数をコンパイルすると、主にコンパイル時に解決する必要があるC ++で同じ名前のオーバーロードされた関数を使用できるため、関数に特別な名前が付けられることを理解しています。Cでは、関数の名前は同じままか、おそらくその前に_が付いています。

私のクエリは：C ++コンパイラがC関数を壊すことを許可することの何が問題になっていますか？コンパイラがそれらに付ける名前は問題ではないと私は思いました。CおよびC ++でも同じように関数を呼び出します。

上記のように答えられましたが、状況を把握するようにします。

まず、Cが最初に来ました。したがって、Cが行うことは、一種の「デフォルト」です。名前をマングルしないので、名前をマングルしません。関数名は関数名です。グローバルはグローバルなどです。

その後、C ++が登場しました。C ++は、Cと同じリンカーを使用し、Cで記述されたコードとリンクできるようにしたいと考えていました。しかし、C ++は、Cを「マングリング」（またはその欠如）のままにすることはできませんでした。次の例を確認してください。

int function(int a);
int function();

C ++では、これらは個別の本体を持つ個別の関数です。それらのいずれもマングルされていない場合、両方とも「関数」（または「_function」）と呼ばれ、リンカはシンボルの再定義について文句を言うでしょう。C ++の解決策は、引数の型を関数名に変換することでした。したがって、1つが呼び出され、もう1つが呼び出さ_function_intれ_function_void（実際のマングリング方式ではない）、衝突が回避されます。

今、私たちは問題を抱えています。場合はint function(int a)Cモジュールで定義された、と我々は単にC ++コードにそのヘッダ（すなわち宣言）を取り、それを使っていると、コンパイラは輸入にリンカに指示を生成します_function_int。関数が定義されたとき、Cモジュールではそれは呼び出されませんでした。と呼ばれました_function。これにより、リンカエラーが発生します。

このエラーを回避するために、関数の宣言中に、Cコンパイラとリンクするか、Cコンパイラでコンパイルするように設計された関数であることをコンパイラに通知します。

extern "C" int function(int a);

C ++コンパイラー_functionは_function_int、ではなくインポートすることを認識し、すべて順調です。

彼らが「できない」というわけではなく、一般的にそうではありません。

と呼ばれるCライブラリの関数を呼び出したい場合foo(int x, const char *y)、C ++コンパイラがそれをfoo_I_cCP()（または、ここではその場でマングリングスキームを作成しただけで）マングルできるようにしても、できません。

その名前は解決されません。関数はCにあり、その名前は引数の型のリストに依存しません。したがって、C ++コンパイラはこれを認識し、マングリングを回避するためにその関数をCとしてマークする必要があります。

上記のC関数は、ソースコードのないライブラリに含まれている可能性があることを覚えておいてください。したがって、C ++コンパイラは「それ自体」のものを実行できません。結局、ライブラリの内容を変更することはできません。

C ++コンパイラがC関数を壊すのを許可することの何が問題になっていますか？

それらはもはやC関数ではありません。

関数は単なるシグネチャや定義ではありません。関数がどのように機能するかは、主に呼び出し規約などの要因によって決まります。プラットフォームで使用するために指定された「アプリケーションバイナリインターフェース」は、システムが相互に通信する方法を説明します。システムで使用されているC ++ ABIは名前マングリング方式を指定しているため、そのシステム上のプログラムは、ライブラリなどの関数を呼び出す方法を認識しています。（すばらしい例については、C ++ Itanium ABIを読んでください。なぜそれが必要なのかがすぐにわかります。）

システムのC ABIにも同じことが当てはまります。一部のC ABIには実際に名前マングリングスキーム（Visual Studioなど）があるため、特定の関数については、「名前マングリングをオフにする」よりも、C ++ ABIからC ABIに切り替えることについて説明します。C関数は、C ABI（C ++ ABIではなく）が適切なC関数であるとマークします。宣言は定義と一致する必要があります（同じプロジェクト内か、一部のサードパーティライブラリ内のいずれかである場合）。そうでない場合、宣言は無意味です。それがなければ、あなたのシステムはそれらの関数を見つけて呼び出す方法を知らないだけです。

プラットフォームがCとC ++のABIを同じであると定義せずにこの「問題」を取り除く理由については、それは部分的に歴史的です—元のC ABIは、名前空間、クラス、および演算子のオーバーロードがあるC ++には十分ではありませんでした。なにかコンピュータにやさしい方法でシンボルの名前で表す必要がありますが、CプログラムをC ++に準拠させることは、Cコミュニティでは不公平であると主張する人もいるかもしれません。 ABIは、相互運用性を必要とする他の一部の人々のためにだけあります。

MSVCは、単純な方法ですが、実際には C名を壊します。それは時々追加する@4か、または別の小さな数字です。これは、呼び出し規約とスタックのクリーンアップの必要性に関連しています。

したがって、前提には欠陥があります。

部分的にCで記述され、部分的に他の言語（多くの場合、アセンブリ言語ですが、Pascal、FORTRAN、またはその他）で記述されたプログラムを持つことは非常に一般的です。また、すべてのソースコードを持っているわけではないさまざまな人々によって作成されたさまざまなコンポーネントがプログラムに含まれていることもよくあります。

ほとんどのプラットフォームには、ABI [Application Binary Interface]と呼ばれる仕様があります。これは、特定の型の引数を受け入れ、特定の型の値を返す特定の名前の関数を生成するためにコンパイラーが実行する必要があることを記述します。場合によっては、ABIが複数の「呼び出し規約」を定義することがあります。そのようなシステムのコンパイラは、特定の関数に使用する呼び出し規約を示す手段を提供することがよくあります。たとえば、Macintoshでは、ほとんどのツールボックスルーチンがPascal呼び出し規約を使用するため、「LineTo」などのプロトタイプは次のようになります。

/* Note that there are no underscores before the "pascal" keyword because
   the Toolbox was written in the early 1980s, before the Standard and its
   underscore convention were published */
pascal void LineTo(short x, short y);

プロジェクト内のすべてのコードが同じコンパイラを使用してコンパイルされた場合、コンパイラが各関数にエクスポートした名前は問題ではありませんが、多くの状況では、Cコードが他のツールを使用してコンパイルされた関数を呼び出す必要があり、現在のコンパイラで再コンパイルすることはできません[C言語で作成されていない可能性もあります]。したがって、そのような関数を使用するには、リンカー名を定義できることが重要です。

私が行った接線方向の議論のいくつかに対処するために、もう1つの答えを追加します。

C ABI（アプリケーションバイナリインターフェイス）は、元々スタックに引数を逆の順序で渡すことを求めていました（つまり、右から左にプッシュされました）。この場合、呼び出し元もスタックストレージを解放します。現代のABIは実際には引数を渡すためにレジスターを使用しますが、マングル化の考慮事項の多くは、元のスタック引数の受け渡しに戻ります。

対照的に、元のPascal ABIは引数を左から右にプッシュし、呼び出し先は引数をポップする必要がありました。オリジナルのC ABIは、2つの重要な点でオリジナルのPascal ABIより優れています。引数のプッシュ順序は、最初の引数のスタックオフセットが常にわかっていることを意味し、未知の数の引数を持つ関数を許可します。初期の引数は、他の引数の数を制御します（ala printf）。

C ABIが優れている2番目の方法は、呼び出し元と呼び出し先が引数の数に同意しない場合の動作です。Cの場合、実際に最後の引数を過ぎて引数にアクセスしない限り、何も悪いことは起こりません。Pascalでは、誤った数の引数がスタックからポップされ、スタック全体が破損します。

オリジナルのWindows 3.1 ABIはPascalに基づいていました。そのため、Pascal ABI（左から右の順序の引数、呼び出し先ポップ）を使用しました。引数番号の不一致はスタックの破損につながる可能性があるため、マングリング方式が形成されました。各関数名は、その引数のサイズ（バイト単位）を示す数値でマングルされました。したがって、16ビットマシンでは、次の関数（C構文）を使用します。

int function(int a)

は2バイト幅なfunction@2ので、にマングルされましたint。これは、宣言と定義が一致しない場合に、リンカが実行時にスタックを破壊するのではなく、関数を見つけられないようにするために行われました。逆に、プログラムがリンクしている場合は、呼び出しの最後にスタックから正しいバイト数が確実にポップされます。

32ビットWindows以降では、stdcall代わりにABIを使用します。これはPascal ABIに似ていますが、Cの場合と同様に、右から左へのプッシュ順です。Pascal ABIのように、名前のマングリングは、引数のバイトサイズを関数名に変換して、スタックの破損を回避します。

ここの他の場所で行われた主張とは異なり、C ABIはVisual Studioであっても関数名を壊しません。逆に、stdcallABI仕様で装飾されたマングリング関数は、VSに固有のものではありません。Linux用にコンパイルする場合でも、GCCはこのABIもサポートします。これは、独自のローダーを使用してLinuxコンパイル済みバイナリをWindowsコンパイル済みDLLに実行時にリンクできるようにするWineで広く使用されています。

C ++コンパイラは、名前の変換を使用して、他の方法ではシグネチャが同じになるオーバーロードされた関数に一意のシンボル名を許可します。基本的には、引数のタイプもエンコードします。これにより、関数ベースのレベルでのポリモーフィズムが可能になります。

Cは関数のオーバーロードを許可しないため、これを必要としません。

名前のマングリングは 'C ++ ABI'に依存できない理由の1つ（ただし、唯一ではない！）であることに注意してください。

C ++は、それに対してリンクする、またはそれに対してリンクするCコードと相互運用できることを望んでいます。

Cは、名前がマングルされていない関数名を想定しています。

C ++がそれをマングルした場合、Cからエクスポートされたマングルされていない関数が見つからないか、CがC ++がエクスポートした関数が見つかりません。Cリンカは、それがC ++から来ているのかC ++に向かっているのかわからないため、Cリンカはそれ自体が期待する名前を取得する必要があります。

C関数と変数の名前をマングリングすると、リンク時にそれらの型をチェックできます。現在、すべての（？）C実装では、1つのファイルで変数を定義し、別のファイルで関数として呼び出すことができます。または、間違ったシグネチャを使用して関数を宣言することもできます（たとえばvoid fopen(double)、それを呼び出します）。

私は1991年にマングルを使用してCの変数と関数を型保証された形でリンクするスキームを提案しました。このスキームは採用されたことはありません。