C ++ 11は、動的/共有ライブラリ境界間でstd libオブジェクトを渡す懸念に対処しましたか？（つまり、dllなど）？

C ++についての私の主な不満の1つは、動的ライブラリ（つまり、dll / so）境界の外側にstdライブラリオブジェクトを渡すことが実際にはどれほど難しいかということです。

stdライブラリは、多くの場合ヘッダーのみです。これは、いくつかの素晴らしい最適化を行うのに最適です。ただし、dllの場合、それらは多くの場合、stdライブラリコンテナの内部構造/コードに影響する可能性のある異なるコンパイラ設定で構築されます。たとえば、MSVCでは、1つのdllがイテレータデバッグをオンにしてビルドされ、別のdllがオフでビルドされます。これらの2つのdllは、stdコンテナーを渡す問題に遭遇する可能性があります。std::stringインターフェイスで公開すると、クライアントが使用しているコードがstd::stringライブラリのに完全に一致することを保証できませんstd::string。

これにより、デバッグや頭痛などの問題が発生しやすくなります。組織内のコンパイラ設定を厳密に制御してこれらの問題を防ぐか、これらの問題のない単純なCインターフェイスを使用します。または、クライアントが使用するはずの予想されるコンパイラ設定を指定します（別のライブラリが他のコンパイラ設定を指定する場合、これは問題になります）。

私の質問は、C ++ 11がこれらの問題を解決するために何かを試みたかどうかです。

すべてのSTL（実際には、テンプレート化されたサードパーティライブラリのすべて）は、すべてのパブリックC ++ APIで回避するのが最善であることは正しいです。また、http： //www.ros.org/reps/rep-0009.html#definitionの規則の長いリストに従って、公開C ++ APIのプログラミングを面倒なものにするABIの破損を防ぐこともできます。

そして、C ++ 11に関する答えはノーです。この標準はそれに触れていません。もっと面白いのはなぜですか？答えは、C ++ 17が非常に感動的であり、C ++モジュールを実装するには、エクスポートされたテンプレートが動作する必要があり、そのためには、フルASTをディスクにダンプしてから、呼び出し元に依存するルックアップを実行して、大規模なC ++プロジェクトの多くのODR違反ケースを処理します-ちなみに、これには多くのGCCおよびELFコードが含まれています。

最後に、多くのMSVCの嫌悪感とプロGCCのコメントがあります。これらは非常に誤った情報を与えられています-ELF上のGCCは基本的に、そして回復不能な、有効で正しいC ++コードを生成することができません。この理由はたくさんありますが、私はすぐに1つの例を引用します：ELFのGCCは、Boost.Pythonに基づいた複数の拡張がPythonにロードされるBoost.Pythonを使用して記述されたPython拡張を安全に生成できません。これは、グローバルCシンボルテーブルを備えたELFは、セグメンテーション違反を引き起こすODR違反を防止するための設計では単純に不可能であるためです。さらに多くの問題があります：最近答えたStackOverflowを見てくださいhttps://stackoverflow.com/questions/14268736/symbol-visibility-exceptions-runtime-error/14364055#14364055たとえば、C ++例外のスローがELFで基本的に完全に壊れている場合。

最後のポイント：異なるSTLの相互運用に関して、これは、一部のSTL実装に緊密に統合されたサードパーティライブラリを混在させようとする多くの大企業ユーザーにとって大きな痛みです。唯一の解決策は、C ++がSTL相互運用を処理するための新しいメカニズムであり、その間、コンパイラ相互運用も修正して、MSVC、GCC、clangコンパイル済みオブジェクトファイルを混在させることができます。 。私はC ++ 17の取り組みを見て、今後数年でそこに何が現れるのかを見るだろう-何もしなければ驚くだろう。

仕様にこの問題があったことはありません。これは、「1つの定義ルール」と呼ばれる概念があり、実行中のプロセスで各シンボルに1つの定義のみが必要であるためです。

Windows DLLはこの要件に違反しています。それがこれらの問題がすべてある理由です。したがって、C ++標準化委員会ではなく、Microsoftが修正する必要があります。Unixではこの問題は発生しませんでした。共有ライブラリは異なる動作をし、デフォルトでは1つの定義ルールに準拠しているためです（明示的に破ることができますが、明らかに余裕があり、余裕があり、いくつかの余分なサイクルを絞る必要がある場合のみ）。

Windows DLLは、次の理由で1つの定義ルールに違反しています。

• 静的リンク時にシンボルが使用されるダイナミックライブラリのハードコードを作成し、それらを定義するライブラリ内でシンボルを静的に解決します。そのため、同じウィークシンボルが複数の共有ライブラリで生成され、それらのライブラリが単一のプロセスで使用される場合、動的リンカーはそれらのシンボルをマージする機会がありません。通常、このようなシンボルは、テンプレートインスタンスの静的メンバーまたはクラス障害であり、異なるDLLのコード間でインスタンスを渡すときに問題を引き起こします。
• コンパイル中に既にシンボルが動的ライブラリからインポートされるかどうかをハードコードします。したがって、一部のライブラリに静的にリンクされたコードは、同じライブラリに動的にリンクされたコードと互換性がありません。

ELF形式のエクスポートを使用するUnixは、最初の問題を回避するためにエクスポートされたすべてのシンボルを暗黙的にインポートし、2番目を回避するために静的リンク時間まで静的および動的に解決されたシンボルを区別しません。

もう1つの問題は、コンパイラフラグです。この問題は、複数のコンパイルユニットで構成されるプログラムに存在し、動的ライブラリを使用する必要はありません。ただし、Windowsではさらに悪化します。Unixでは、静的にリンクするか動的にリンクするかは実際には関係ありません。とにかく標準ランタイムを静的にリンクする人はいません（Linuxでは違法かもしれません）。特別なデバッグランタイムはないので、1つのビルドで十分です。しかし、Microsoftが静的および動的リンク、デバッグおよびリリースランタイム、その他のオプションを実装した方法は、必要なライブラリバリアントの組み合わせの爆発を引き起こしたことを意味します。繰り返しますが、C ++言語の問題ではなくプラットフォームの問題です。

いや

ヘッダーシステムを置き換えるために多くの作業が行われています。ヘッダーシステムは、モジュールと呼ばれ、これに影響を与える可能性がありますが、大きなものではありません。