私は古いスタイルの C に慣れており、最近 c99 の機能を調べ始めたばかりです。1 つだけ質問があります。プログラムで c99 を使用し、c99 フラグを使用gcc
して以前の c99 ライブラリとリンクすると、プログラムは正常にコンパイルされますか?
では、古い C89 に固執するか、進化する必要がありますか?
その点では相性がいいと思います。それは、あなたがコンパイルしているものが新しいグッズを踏まない限りです. たとえば、古いコードに含まれてenum bool { false, true };
いる場合、問題が発生しています。同じような恐竜として、私はゆっくりと C99 の素晴らしい新しい世界を受け入れています。結局のところ、それは約 10 年間そこに潜んでいるだけです ;)
あなたは進化するべきです。聞いてくれてありがとう :-)
実際、私はそれを拡張します。
C99 がかなり前から存在していたことは間違いありません。(私の意見では) その標準をレガシー コード (新しい機能を追加するのではなくバグを修正するだけのコード) 以外には使用する必要があります。レガシー コードにはおそらく価値はありませんが、(すべてのビジネス上の決定と同様に) 独自の費用対効果分析を行う必要があります。
新しいコードが C1x と互換性があることは既に確認しています。新しい機能はまだ使用していませんが、壊れないようにしています。
どのコードに注意する必要があるかについて、標準の作成者は後方互換性を非常に重視しています。彼らの仕事は、新しい言語を設計することではなく、既存の慣行を体系化することでした。
彼らが現在いるフェーズでは、言語を更新する自由度がいくらかありますが、アウトプットに関してはヒポクラテスの誓いに従います。「まず第一に、害を及ぼさない」.
通常、コードが新しい標準で壊れている場合、コンパイラは強制的に通知します。そのため、コード ベースをコンパイルするだけでも、優れた出発点となります。ただし、C99 の論理的根拠のドキュメントを読むと、 「静かな変化」というフレーズが表示されます。これには注意が必要です。
これらは、通知する必要のないコンパイラの動作の変更であり、アプリケーションが異常な動作を開始した場合、多くの不安と歯ぎしりの原因となる可能性があります。「c89 の静かな変更」ビットについて心配する必要はありません。それらが問題である場合は、すでにそれらに噛まれているはずです。
ところで、そのドキュメントは、実際の標準がその内容を述べている理由を理解するための優れた読み物です。
C ライブラリ間の呼び出し規約は何年も変わっていません。
この時点で、オペレーティング システムは C の呼び出し規則に大きく依存しています。これは、C API が OS の断片間の接着剤となる傾向があるためです。
したがって、基本的に答えは「はい、バイナリは下位互換性があります。いいえ、当然、C99 機能を使用するコードは、後で非 C99 コンパイラでコンパイルすることはできません」です。
敬意を表して:試してみてください。:-)
ただし、いくつかの小さなコンパイルの違いを修正する必要がある場合でも、上に移動する価値があることに注意してください。
下位互換性を保つことを目的としています。多くのベンダーがすでに実装している拡張機能を形式化します。適切に作成されたプログラムは、C99 でコンパイルしても問題が発生しない可能性があります。
私の経験では、時間を節約するために一部のモジュールを再コンパイルし、他のモジュールを再コンパイルしないことは...多くの時間を無駄にします。通常、すべての互換性を確保するために新しいコンパイラを必要とする、見過ごされやすい詳細がいくつかあります。