プラグインによる。
vi でロードされdlopen()、そのシンボルがdlsym()(ランタイム システムによって動的にロードされる標準のシャード ライブラリではなく) 経由で解決されるライブラリを意味します。
http://www.isotton.com/howtos/C++-dlopen-mini-HOWTO/を参照してください。ドキュメントは 2006 年に最後に更新されました。extern "C"関数名のマングリングを防ぐために を使用することをお勧めします。これにより、dlsymその関数を比較的簡単に見つけることができます。
これはまだ動的ライブラリに関連していますか? 私の特定のケースでは、libtool を使用して OSX で動的ライブラリを作成しようとしています。おそらく、使用__attribute__ ((constructor))はよりヒップで現代的ですが、推奨されるプラクティスを発見することにほとんど成功していません.
extern "C"マングルされていない関数を C++ コードからエクスポートする最良の方法は、今でも確信しています。問題なく複数のプラットフォームで使用できます。
ライブラリを手動でロードし、関数/オブジェクトの取得と解決にdlopen()使用する場合は、extern "C" 名を使用するとはるかに簡単になります。dlsym()マングルされた名前にとっては苦痛です。
したがって、より簡単な移植性/使いやすさが必要な場合は、C (extern "C") インターフェイスを使用してください。
ただし、C (extern "C") インターフェイスを公開することの短所を考慮する必要があります。
これは、インターフェイスを介して直接 C++ オブジェクトを公開できないことを意味します。したがって、最初は RAII のような多くの機能が失われます。C インターフェースへの呼び出しをラップする追加のラッパー呼び出しを作成して、これを補う必要があります。
元の質問は共有ライブラリに関するものでした (コメントを介してのみ、プラグイン共有ライブラリに関するものであることがわかりました)。
そのため、名前は管理できません。
コンパイラ/ランタイムがシンボルを解決している場合、これは問題ではありません。
複数のコンパイラを使用する予定はありますか? これが C インターフェイスをエクスポートする唯一の理由です (異なる C++ コンパイラは異なる ABI を使用することが多いため)。
同じコンパイラを使用している場合は、C++ インターフェイスを使用しないでください。
個人的には、特定のプラットフォームで 1 つのコンパイラーのみを使用し、そのプラットフォームで共有オブジェクトのみを使用します。コンパイラがアップグレードされた場合、何か大きな問題が発生した場合、とにかくすべてのライブラリを再構築しています。