C ++ 17、C ++ 14、およびC ++ 11オブジェクトをリンクしても安全ですか

Question 1

3つのコンパイル済みオブジェクトがあり、すべて同じコンパイラ/バージョンで生成されているとします。

AはC ++ 11標準でコンパイルされました
BはC ++ 14標準でコンパイルされました
CはC ++ 17標準でコンパイルされました

簡単にするために、すべてのヘッダーがC ++ 11で記述されており、3つの標準バージョン間でセマンティクスが変更されていない構成体のみを使用しているため、相互依存関係がヘッダーインクルードで正しく表現され、コンパイラーが異議を唱えなかったとします。

これらのオブジェクトのどの組み合わせがそれであり、単一のバイナリにリンクするのは安全ではありませんか？どうして？

編集：主要なコンパイラ（gcc、clang、vs ++など）に関する回答を歓迎します

Question 2

これらのオブジェクトのどの組み合わせがそれであり、単一のバイナリにリンクするのは安全ではありませんか？どうして？

GCCの場合、オブジェクトA、B、Cの任意の組み合わせをリンクしても安全です。それらがすべて同じバージョンでビルドされ、ABI互換である場合、標準バージョン（つまり、-stdオプション）は違いを生じません。

どうして？それは、実装の重要な特性であり、確保するために私たちが懸命に取り組んでいるためです。

問題があるのは、異なるバージョンのGCCでコンパイルされたオブジェクトをリンクすると、し、GCCによるその標準のサポートが完了する前に新しいC ++標準の不安定な機能を使用場合です。たとえば、GCC 4.9を使用してオブジェクトをコンパイルし、-std=c++11GCC 5 を使用して別のオブジェクトをコンパイルすると、-std=c++11問題が発生します。C ++ 11のサポートはGCC 4.xで試験的に行われたため、C ++ 11機能のGCC 4.9バージョンと5バージョンの間には互換性のない変更がありました。同様に、GCC 7で1つのオブジェクトをコンパイル-std=c++17し、GCC 8で別のオブジェクトをコンパイルした場合-std=c++17、GCC 7および8でのC ++ 17サポートはまだ実験的で進化しているため、問題が発生します。

一方、次のオブジェクトの任意の組み合わせが機能します（ただし、libstdc++.soバージョンについては下記の注を参照してください）。

GCC 4.9でコンパイルされたオブジェクトDおよび -std=c++03
GCC 5でコンパイルされたオブジェクトEおよび -std=c++11
GCC 7でコンパイルされたオブジェクトFおよび -std=c++17

これは、使用されている3つのコンパイラバージョンすべてでC ++ 03サポートが安定しているため、C ++ 03コンポーネントはすべてのオブジェクト間で互換性があるためです。C ++ 11サポートはGCC 5以降は安定していますが、オブジェクトDはC ++ 11機能を使用せず、オブジェクトEとFはどちらもC ++ 11サポートが安定しているバージョンを使用します。C ++ 17のサポートは、使用されているどのコンパイラバージョンでも安定していませんが、オブジェクトFのみがC ++ 17機能を使用しているため、他の2つのオブジェクトとの互換性の問題はありません（共有する機能はC ++ 03のみです）またはC ++ 11、および使用されているバージョンにより、これらのパーツは正常に機能します）。後でGCC 8を使用して4番目のオブジェクトGをコンパイルする場合、-std=c++17FとGのC ++ 17シンボルに互換性がないため、Fを同じバージョンで再コンパイルする（またはFにリンクしない）必要があります。

上記のD、E、F間の互換性に関する唯一の注意点は、プログラムがlibstdc++.soGCC 7以降の共有ライブラリを使用する必要があることです。オブジェクトFはGCC 7でコンパイルされたので、そのリリースの共有ライブラリを使用する必要があります。GCC7でプログラムの一部をコンパイルすると、libstdc++.soGCC 4.9またはGCC 5に存在しないシンボルへの依存関係が導入される可能性があるためです。 GCC 8で構築されたオブジェクトGにリンクする場合は、libstdc++.so、GCC 8 from Gが必要とするすべてのシンボルを確実に検出する必要があります。単純なルールは、プログラムが実行時に使用する共有ライブラリが、少なくともオブジェクトのコンパイルに使用されるバージョンと同じくらい新しいことを確認することです。

GCCを使用する際のもう1つの注意点は、質問のコメントですでに述べたように、GCC 5以降、libstdc ++ でstd::string使用できる実装が2つあることです。2つの実装はリンク互換ではありません（マングル名が異なるため、一緒にリンクできません）が、同じバイナリ内で共存できます（マングル名が異なるため、1つのオブジェクトstd::stringがその他の用途std::__cxx11::string）。オブジェクトが使用する場合std::string、通常はすべて同じ文字列実装でコンパイルする必要があります。でコンパイルし-D_GLIBCXX_USE_CXX11_ABI=0て元のgcc4-compatible実装-D_GLIBCXX_USE_CXX11_ABI=1を選択するか、新しい実装を選択しますcxx11実装（名前に騙されないでください。C++ 03でも使用できます。cxx11C ++ 11要件に準拠しているため）。デフォルトの実装は、GCCの構成方法によって異なりますが、デフォルトでは、マクロを使用してコンパイル時に常にオーバーライドできます。

Question 3

答えには2つの部分があります。コンパイラーレベルでの互換性とリンカーレベルでの互換性。前者から始めましょう。

すべてのヘッダーがC ++ 11で記述されているとしましょう

同じコンパイラを使用すると、ターゲットのC ++標準に関係なく、同じ標準ライブラリヘッダーとソースファイル（コンパイラに関連付けられた1回）が使用されます。したがって、標準ライブラリのヘッダーファイルは、コンパイラがサポートするすべてのC ++バージョンと互換性があるように記述されています。

つまり、翻訳単位のコンパイルに使用されるコンパイラオプションが特定のC ++標準を指定している場合、新しい標準でのみ使用できる機能にはアクセスできません。これは__cplusplusディレクティブを使用して行われます。ベクトルを見る使い方の興味深い例ソースファイルを。同様に、コンパイラーは、新しいバージョンの標準によって提供される構文機能を拒否します。

つまり、想定は、記述したヘッダーファイルにのみ適用されるということです。これらのヘッダーファイルは、異なるC ++標準を対象とする異なる翻訳単位に含まれている場合、非互換性を引き起こす可能性があります。これについては、C ++標準の付録Cで説明されています。4つの条項があります。最初の条項についてのみ説明し、残りは簡単に説明します。

C.3.1条項2：字句の規則

単一引用符は、C ++ 11では文字リテラルを区切りますが、C ++ 14およびC ++ 17では数字の区切り文字です。純粋なC ++ 11ヘッダーファイルの1つに次のマクロ定義があるとします。

#define M(x, ...) __VA_ARGS__

// Maybe defined as a field in a template or a type.
int x[2] = { M(1'2,3'4) };

ヘッダーファイルを含むが、それぞれC ++ 11とC ++ 14をターゲットとする2つの変換単位を検討します。C ++ 11を対象とする場合、引用符内のコンマはパラメーターの区切り文字とは見なされません。パラメータは1つだけです。したがって、コードは次と同等になります。

int x[2] = { 0 }; // C++11

一方、C ++ 14を対象とする場合、一重引用符は桁区切り記号として解釈されます。したがって、コードは次と同等になります。

int x[2] = { 34, 0 }; // C++14 and C++17

ここでのポイントは、純粋なC ++ 11ヘッダーファイルの1つで一重引用符を使用すると、C ++ 14/17をターゲットとする翻訳単位に驚くべきバグが発生する可能性があるということです。したがって、ヘッダーファイルがC ++ 11で記述されている場合でも、それが標準の新しいバージョンと互換性があることを保証するために、慎重に記述する必要があります。の__cplusplusディレクティブは、ここでは有用である可能性があります。

標準の他の3つの条項は次のとおりです。

C.3.2条項3：基本概念

変化する：新しい通常の（配置されない）デアロケーター

根拠：サイズの割り当て解除に必要です。

元の機能への影響：有効なC ++ 2011コードでは、グローバル配置割り当て関数と割り当て解除関数を次のように宣言できます。
void operator new(std::size_t, std::size_t); 
void operator delete(void*, std::size_t) noexcept;
ただし、この国際標準では、演算子の削除の宣言は、事前定義された通常の（配置されない）演算子の削除（3.7.4）と一致する場合があります。その場合、クラスメンバーの割り当て関数と割り当て解除関数（5.3.4）の場合と同様に、プログラムの形式が正しくありません。

C.3.3条項7：宣言

変更：constexpr非静的メンバー関数は暗黙的にconstメンバー関数ではありません。

根拠：constexprメンバー関数がオブジェクトを変更できるようにするために必要です。

元の機能への影響：有効なC ++ 2011コードは、この国際標準でコンパイルできない場合があります。

たとえば、次のコードはC ++ 2011では有効ですが、同じ国際標準では無効です。これは、同じメンバー関数を異なる戻り値の型で2回宣言しているためです。
struct S {
constexpr const int &f();
int &f();
};

C.3.4節27：入出力ライブラリ

変更：取得が定義されていません。

根拠：getの使用は危険と見なされます。

元の機能への影響：この国際規格では、gets関数を使用する有効なC ++ 2011コードはコンパイルに失敗する場合があります。

C ++ 14とC ++ 17の間の潜在的な非互換性については、C.4で説明します。非標準のヘッダーファイルはすべてC ++ 11で記述されているため（質問で指定されているとおり）、これらの問題は発生しないため、ここでは触れません。

次に、リンカーレベルでの互換性について説明します。一般に、非互換性の潜在的な理由は次のとおりです。

オブジェクトファイルの形式。
プログラムの起動および終了ルーチンとmainエントリポイント。
プログラム全体の最適化（WPO）。

結果のオブジェクトファイルの形式がターゲットのC ++標準に依存する場合、リンカーは異なるオブジェクトファイルをリンクできなければなりません。GCC、LLVM、およびVC ++では、幸いにもそうではありません。つまり、オブジェクトファイルのフォーマットは、ターゲット標準に関係なく同じですが、コンパイラ自体に大きく依存しています。実際、GCC、LLVM、およびVC ++のどのリンカーも、ターゲットのC ++標準に関する知識を必要としません。これは、コンパイル済みのオブジェクトファイルをリンクできることも意味します（ランタイムを静的にリンクします）。

プログラムの起動ルーチン（を呼び出す関数main）がC ++標準ごとに異なり、異なるルーチンが互いに互換性がない場合、オブジェクトファイルをリンクすることはできません。GCC、LLVM、およびVC ++では、幸いにもそうではありません。さらに、の署名main関数（およびそれに適用される制限、標準のセクション3.6を参照）はすべてのC ++標準で同じであるため、どの翻訳単位が存在するかは関係ありません。

一般に、WPOは、異なるC ++標準を使用してコンパイルされたオブジェクトファイルではうまく機能しない可能性があります。これは、コンパイラのどのステージがターゲット標準の知識を必要とするか、どのステージが必要としないか、およびオブジェクトファイルをまたぐプロシージャ間の最適化に与える影響に正確に依存します。幸い、GCC、LLVM、VC ++は適切に設計されており、この問題はありません（私が認識していることではありません）。

したがって、GCC、LLVM、およびVC ++は、C ++標準の異なるバージョン間でのバイナリ互換性を可能にするように設計されています。ただし、これは規格自体の要件ではありません。

ちなみに、VC ++コンパイラは、C ++標準の特定のバージョンをターゲットにできるstdスイッチを提供していますが、C ++ 11のターゲットはサポートしていません。指定できる最小バージョンはC ++ 14です。これは、Visual C ++ 2013 Update 3以降のデフォルトです。古いバージョンのVC ++を使用してC ++ 11をターゲットにすることもできますが、別のVC ++コンパイラを使用する必要があります。 C ++標準のさまざまなバージョンを対象とするさまざまな翻訳単位をコンパイルします。これにより、少なくともWPOが機能しなくなります。

警告：私の答えは完全ではないか、非常に正確ではないかもしれません。

Question 4

新しいC ++標準には、言語機能と標準ライブラリコンポーネントの2つの部分があります。

あなたがで平均として新しい標準、（例えば遠隔-のために）言語自体に変更は問題はほとんどありません（時には競合は、新しい標準言語機能を持つサードパーティのライブラリヘッダ内に存在しています）。

しかし、標準ライブラリ...

各コンパイラバージョンには、C ++標準ライブラリの実装（gccを使用したlibstdc ++、clangを使用したlibc ++、VC ++を使用したMS C ++標準ライブラリなど）と1つの実装が含まれますが、各標準バージョンの実装は多くありません。また、提供されているコンパイラー以外の標準ライブラリーの実装を使用する場合もあります。注意する必要があるのは、古い標準ライブラリの実装を新しいものにリンクすることです。

サードパーティライブラリとコードの間で発生する可能性のある競合は、そのサードパーティライブラリにリンクする標準ライブラリ（および他のライブラリ）です。