最近、gcc で生成されたオブジェクト ファイル ( CCgnu makefile マクロを使用) を g++ にリンクして、共有オブジェクト ライブラリを作成するプロジェクトに出会いました。
名前マングリングの問題を回避するためにソースコードがコンストラクト内にカプセル化されていることを (おそらく) 保証する以外に、#ifdef __cplusplus / extern "c" { / #endifこれが...より良い理由はありますか?
最近、gcc で生成されたオブジェクト ファイル ( CCgnu makefile マクロを使用) を g++ にリンクして、共有オブジェクト ライブラリを作成するプロジェクトに出会いました。
名前マングリングの問題を回避するためにソースコードがコンストラクト内にカプセル化されていることを (おそらく) 保証する以外に、#ifdef __cplusplus / extern "c" { / #endifこれが...より良い理由はありますか?
それらがプリプロセッサチェックを追加することとのみリンクし、役に立たない場合、それはすでに行われたリンク段階での前処理とコンパイルにのみ影響します。g++extern "C"
例外がCライブラリを介して伝播できるようにしたかったかもしれませんが、そのためには、libstdc++ではなくlibgccにリンクするだけで済みます。
おそらく、共有ライブラリをlibstdc ++に依存させたいだけなので、ライブラリのユーザーもlibstdc ++に依存し、明示的にリンクする必要はありませんが、期待どおりに機能しない可能性があります。
つまり、すべてのコードがC ++コードではなく、Cコードである場合、私は正当な理由を考えることができません。
ただし、何かがgccCコードでコンパイルされているからといって、gcc実行可能ファイルを使用してC ++コードをコンパイルすると、Cフロントエンド(cc1plus)の代わりにC ++フロントエンド()が呼び出されcc1ます。C ++コードが標準ライブラリを使用している場合は、とリンクする-lstdc++ か、リンクに使用g++する必要があります(自動的にリンクします-lstdc++)。したがって、おそらく答えは、それがC ++コードであり、オブジェクトをコンパイルしたという事実は、それがCコードであると思わせgccなかったということです。g++