- ベストアンサー
コンパイラの互換性について
コンパイラの互換性について教えてください。違うコンパイラで作成したShared Objectを使用するプログラムの動作が不安定になるといったことは考えられますか?考えられるとすれば、どのような理由でそういった事象が発生するのでしょうか? WindowsではMSのコンパイラとBorlandのコンパイラについて。 SolarisではSUNのコンパイラとGNUのコンパイラについて。 Linuxでは異なるバージョンのGNUコンパイラについて。 現状を教えてください。 ここらへんを解説している書籍やURLの紹介も嬉しいです。
- みんなの回答 (2)
- 専門家の回答
質問者が選んだベストアンサー
ELFやPEはヘッダ情報を含む全体のフォーマットでOS依存情報(より正確にはローダー依存)を含みます。 COFFはオブジェクトカーネル部分のみを指し、OS依存部分を含みません。 UNIX版gccで出力にa.outフォーマットを指定した場合は伝統的なa.outフォーマットになるのですが、これはCOFFとは明らかに違います。 > 非インターフェース部分の隠遮が… COMに関する記述なので「インタフェース部分」はIUnknownとIDispatchを指すものと思われます。 #1の回答中で使用している「インターフェース」とは意味合いが違いますので、ご注意ください。 結果、「非インターフェース部分の隠蔽が…」に関する対応としては >> コンパイルオプションやプリプロセッサ構文、処理系依存の拡張機能を駆使してプログラマが保証する必要があります。 と言うことになります。 対象となるコンパイラのコードジェネレータ、オプティマイザに対する深く正確な知識が必要となります。
その他の回答 (1)
- toysmith
- ベストアンサー率37% (570/1525)
質問文に挙げられているコンパイラの出力オブジェクトファイルは全てCOFF(Common Object File Format)です。 COFFは「オブジェクトファイル記述言語」であり、オブジェクトフォーマット定義をオブジェクトファイル内に持ちます。 結果、「オブジェクトファイルフォーマットの食い違いによる不具合」は(論理的には)ありません。 リンキング時(ダイナミックリンク、スタティックリンクに関わらず)に問題になりそうな仕様の差異についてはCOFFフォーマットが規定するコマンドが吸収可能です。 インターフェースミスマッチング(スタック/レジスタの使い方や引数評価順序の違いなど)についてはコンパイルオプションやプリプロセッサ構文、処理系依存の拡張機能を駆使してプログラマが保証する必要があります。 ただし、「理論的にありえないことが実際には良く起こる」という法則は(残念ながら)生きていますので「オブジェクトファイル依存の不具合は絶対にない」と断言は出来ません。 オブジェクトフォーマット、関数インターフェース、記憶領域管理に関してはCOFFの機能、プログラマの努力で(理論的には)互換性を確保することが出来ます。 しかし、オブジェクトファイルに含まれるモジュールが利用する下位モジュールについては互換性が確保される保証がありません。
お礼
早速のご回答ありがとうございます。 出力形式についてですが Solaris、Linux → ELF Windows → PE と考えていたんですが、大きな意味ではCOFFとほとんど同じという意味でしょうか? 「非インターフェース部分の隠遮がバイナリレベルで保障されていないため、コンパイラの違いによる問題が発生することがある」という記述をCOMに関しての書籍でみたものですから気になって質問してみたわけです。
お礼
かさねがさね、ありがとうございます。 本の記述の部分では主語が抜けていました。C++に関する記述です。 すいませんでした。