コンパイル済みのC ++ 11ライブラリ（lib、dllなど）を古いC ++コンパイラにリンクできますか？

古いC ++コンパイラ（VS2008やgcc3.4など）は、C ++ 11で記述された外部ライブラリとリンクできますか？

私の考えでは、C ++ 11 .libファイルはこの段階では単なるバイトコードであり、何らかの方法で解決可能かつ呼び出し可能であれば、古いコンパイラの生成方法を気にするべきではありません。

私はAPIがまだC ++ 03ユーザーをサポートする小さなライブラリを開発しています。だから、楽しみにして、std::unique_ptrなどの便利な機能を使用してライブラリを実装しても大丈夫なのか、それとも固執する必要があるのboost::でしょうか？

ライブラリがその実装でC ++ 11のみを使用し、C ++ 11の機能または型を公開しない場合、特に静的リンケージを使用する場合、そうです、これは可能であり標準です。

ライブラリがCレベルのインターフェイスを公開し（最も幅広い種類のクライアントで使用可能）、C ++で内部的に実装されている一般的なケースを考えます。このようなライブラリにリンクするクライアントは、パブリックバイナリAPI（エクスポートされた関数）のみを心配する必要があります。これは、互換性を最大限にするためにレガシーC / C ++に制限されます。Javaプログラムは、C ++で内部的に実装されているCレベルのAPIにリンクできます。これは、Javaが「C ++をサポートする」必要があるという意味ではありません。同様に、古いスタイルのC / C ++クライアントは、内部的にC ++ライブラリまたは他のライブラリのいくつかの前衛バージョンを使用するCレベルまたはC ++レベルのAPIにリンクできます。2つの別個のこと：ライブラリのインターフェイスにリンクするために必要なもの、およびライブラリ自体が内部的にリンクする（または静的に取り込む）もの。

ライブラリのクライアントを実装の依存関係にさらさないでください。

依存関係（C ++ 11またはその他）をライブラリに静的にリンクできる場合、これはクリーンで自己完結型です。ライブラリは真のブラックボックスです。バイトコードにすぎません。ただし、ライブラリが「暗黙の動的」リンケージを介して依存関係にリンクしている場合でも（明示的なLoadLibrary / GetProcAddressの種類および* nixおよびOS Xの同様のメソッドと混同しないでください）、古いクライアントはそのライブラリにリンクできるはずですライブラリが依存しているライブラリにリンクできなくても、パブリックインターフェイス。

他の人が使用するために新しいライブラリを作成し、実装言語としてC + 11を使用したいように思えます。考慮すべき多くの問題があります。

• C ++の新しいバージョンを導入することにより、新しいC ++ランタイムライブラリをライブラリにデプロイする必要性が生じますが、大丈夫ですか？
• あなたがすべきではないそう、彼らはそれを呼び出すことはできません、あなたのパブリックインターフェイスで新しいC + 11型を使用します。
• 一般に、unique_ptr、さらにはvectorなどの複雑なタイプは避けてください。ライブラリをソースコードとして配布する場合を除き、ライブラリ内のオブジェクトのレイアウトはクライアントコードのレイアウトと異なる場合があります。オブジェクトレイアウトのバリエーションのリスクがない単純なタイプに固執します。