プログラムを書くとき、私は不特定または実装定義の振る舞いを避けることを目指しています。C ++ライブラリにリンクするとき、私はそれらが同様の方法で書かれていることを期待しています。コンパイル時に実装定義の動作を使用していたライブラリにリンクすると、すぐに自分のプログラムが標準に従って実装定義になりますか？
この時点でも問題はありませんか？ライブラリがすでにオブジェクトコードにコンパイルされている場合は、実装定義のC ++も扱っていません。実際、C++で記述されていない可能性もあります。POSIXなど、本質的にプラットフォームに依存するAPIを使用する場合はどうでしょうか。
標準の記述方法は、私の「C ++プログラム」が完全に私によって記述されており、他のコンパイル済みコンポーネントを含まないことを前提としているようです。これらのコンポーネントのリンクにどのように対応し、どの時点で標準は私のプログラムの機能を気にしなくなりますか？
未指定（または実装定義、または未定義）の動作を持つ関数を呼び出すと、プログラムの動作は未指定（または実装定義、または未定義）になります。
この規格は、プログラムが「実装定義される」ことの意味を定義していないので、いいえと言う以外にその部分に答えることはできません。あなたのプログラムは、規格に従って実装定義されていません。その動作はです。
Posixから関数を呼び出す場合、プログラムはPosix（のその部分）に依存します。このようなプログラムの動作は、C ++標準だけでは定義されません。これは、C++標準がPosix関数の機能を認識または認識していないためです。ただし、Posix関数が何をするかについての知識があれば、C++標準を使用してプログラム全体が何をするかを理解することができます。したがって、C ++標準の範囲外の部分を除いて、動作はC++標準で定義できます。
ライブラリ内のコードを呼び出さずに、ライブラリにリンクするだけでプログラムに未定義の動作をさせることができる特定の状況もあります。単一定義規則に違反することは明らかな例です。標準に関する限り、と呼ばれる関数を定義する権利がありますが、pthread_createそのプログラムをpthreadに対してリンクすると、未定義の動作が発生します。
Posixやその他のOS機能が「プログラムの一部」であるか「実装の一部」であるかにかかわらず、灰色の領域があります。たとえばstrdup、Posix以外の環境で簡単に実装できるものを考えてみましょう。それが「実装の一部」である場合、もちろんその動作は実装によって定義されます。それが「プログラムの一部」である場合、プログラムの動作は、すべてのC ++プログラムの動作と共通して、プログラムに依存します。C ++標準は、どちらの考え方を選択するかを実際には気にしません。
この規格は、プログラムの作成者の数については何も想定していません。使用するコンポーネントが文書化されている場合、最終的なプログラムをまとめる人として、プログラムの動作を希望どおりに定義する方法で使用したかどうかを判断するのはあなたの責任です。 。それらが文書化されていない場合、または文書に記載されているとおりに動作しない場合は、作成者に、それについて何かをする責任があるという事例を提示することをお勧めします;-)
そのライブラリが標準ライブラリの一部である場合、それは任意の標準準拠プラットフォームで利用可能であり、その動作はそのインターフェイスに関して指定されたとおりであると想定できます。
そうでなければ、できません。また、そのプラットフォームのソースからコンパイルしたり、他の方法で移植したりできるとは限りません。そして、再コンパイルするだけでは、プログラムをそのプラットフォームに移植することはできません。これは、実装で定義された動作なしでプログラムを作成する目的です。