新しいCプロジェクトは、非常に古いC標準（20年以上前、つまりC89）をターゲットにする必要がありますか？

ときどき、非常に古いC標準（通常はC89）をターゲットとする、比較的新しく、オープンソースの主要なCプロジェクトを目にします。例はsystemdです。これらのプロジェクトには実力のある優秀な人材がいるので、おそらく私には分からないこの決定の背後にある合理的な根拠があるでしょう。疑いの利点は別として、論理的結論はFORTRANがCよりも優れており、COBOLはFORTRANよりも優れているという論理的な結論になるため、理論的根拠は「より古く標準化されたものは常により移植性が高く、より優れている」ように思われます。

新しいCプロジェクトが非常に古いC標準を対象とすることはいつ、そしてなぜ正当化されますか？

ユーザーのシステムが絶対にCコンパイラーを更新してはならないが、そうでなければ新しいソフトウェアを自由にインストールできるシナリオを想像することはできません。たとえば、DebianのLTSバージョンには、C99およびC11の一部をサポートするgcc 4.6パッケージがあります。しかし、奇妙なシナリオが存在しなければならず、systemdのようなプログラムがそれらのユーザーをターゲットにしていると思います。

私が想像できる最も合理的なユースケースは、ユーザーがC89コンパイラーのみが利用できるエキゾチックなアーキテクチャーを持っていると予想されるが、彼らは完全に新しいソフトウェアをインストールすることをいとわない場合です。命令セットアーキテクチャの多様性の低下を考えると、それは過度に仮説的なシナリオのように思えますが、私にはわかりません。

...「古いものと標準化されたものは常により移植性が高く、優れています」これはばかげています...

それが良くなると、その陳述はばかげたものになりました。これは完全に主観的です。プロジェクトの言語と標準を選択しないのは、前回のミートアップの参加者の半分がそれを使用していたためです。解決しようとしている問題を研究して理解し、それが仕事に適したツールであると判断したため、選択します。

一般的な標準については、移植性のためにいくつかのプロジェクトで行われるべきケースがあり、それは古いものを選択することが何らかの利益をもたらす場合です。これは、製品としてライブラリを開発している場合に特に当てはまります。これは、他の誰かの目的の手段です。あなたがやりたい最後のことは、あなたがまだ会っていない顧客が利用できないかもしれないコンパイラを必要とするので、あなたが売ることができない何かを書くことです。埋め込まれた世界に関するフィリップケンダルのコメントは注目されています。人々はまだ古い安定したプラットフォーム用の新しいコードを記述する必要があるため、または追加機能の恩恵を受けず、最新のコンパイラーを取得しないため、多くの問題が発生しています。プロジェクトのあらゆる側面を完全に管理している場合、

特にCについては、最新の標準を順守することと引き換えに何を得るかという問題があります。K＆RからC89への移行は大きな変更であり、古いコードをクリーンアップするには多大な労力が必要でしたが、最終的には多くの成果を上げました。C99およびC11の変更比較的小さなものであり、最近開発されたCIの遭遇のほとんどは、新しい機能を使用しないためC89をパスします。1行コメントをサポートし、ネイティブブールデータ型を持ち、可変長配列を実行できるため、C99をC99に委任することは正しいことだと主張するのは困難です。コメントとブール値には-い回避策がなく、VLAは他のわずかに効率の悪い方法で処理できます。C11はVLAをオプションに降格しました。これは、古いC99が実装に顕著に現れている場合に選択することを正当化する可能性があります。

幅広いプラットフォーム間での移植性が重要な場合。これには、廃止されたプラットフォームや、最小限のコンパイラしか使用できない多くの組み込みプロセッサが含まれる場合があります。

C89が「最低公約数」であるという意味もあります。これは最初の適切に標準化されたバージョンであり、現在使用されているほとんどすべてのコンパイラは、C89のスーパーセットを実装すると想定できます。

また、Microsoft Visual C ++は、C ++標準に追いつくのに比較的優れていたものの、CモードではC89に長時間留まっていたという問題もあります。したがって、最新のVisual Studioを使用していない人はC89に制限される可能性があります。

主にマイクロソフトのせいで、まだ完全にC99に準拠していない擬似C89コードを書いていることを認めなければなりません。私はWindows側のMSVCに大きく依存していますが、まだC99に完全には準拠しておらず、代わりにC ++ 17以降に焦点を当てています。

それに加えて、多くのプラグイン開発者がプラグイン開発にMSVCを使用するC SDKに取り組んでおり、一部はまだMSVC 2010です。そのため、あまりエキゾチックではないプラットフォームで広く使用されている人気のあるコンパイラがありますWindowsエキゾチック）C99をまだ完全には実装していません。最大範囲のコンパイラーとの幅広い互換性（SDKがC ++ではなくCで記述されている主な理由の1つ）をターゲットにした場合、時代遅れの多くの（少なくともMSVC）がまだ広く使用されていますCサポートに関しては。C99からほぼ20年が経過し、MSVC AFAIKなどにはまだVLAがありません（MSVC 2017ではまだ確認していませんが、Cに対するマイクロソフトのスタンスを考えると、C99にはるかに準拠しているとは思えません） 。

そのため、残念ながら、C99に完全に準拠していない優れたオプティマイザーとデバッガーを備えた実際に非常に優れた新しいコンパイラーがまだあります。もちろん、これがなければ、C11を飛び回ることになります。

プラグインおよびMSVCとのソース互換性に加えて、他の言語との相互運用もあります。他のいくつかの言語はFFIを介してSDKを使用し、それらのFFIの一部はC89のみを理解します。彼らは理解していない可能性がありますboolか_Bool、簡単な例としてdylibから関数をインポートするときにのみ理解し、言いますint。

はい、賛成の議論は移植性ですが、問題は、C89コンパイラのみを使用できるが、ソフトウェアの新しいディストリビューションをコンパイルしている非仮想システムがあるかどうかです。すなわち、私が新しいCプロジェクトを始めていた場合、C89に準拠することで潜在的なユーザーの数を増やすことができるかどうかをどのように判断できますか？

これに気づいたのBlrflですが、私の場合、C99とC11を使用することによる生産性の向上はそれほど大きくはありませんが、MSVCでプラグインを作成する機能を失うことは大きなコストになる可能性があります（特に私が働いている製品以来onはWindows側で圧倒的に最大の市場シェアを持ち、平均的なユーザーは多くのサードパーティプラグインを購入してダウンロードします。私が取り組んでいる製品の種類は、プログラマー/スクリプター向けの開発環境とアーティスト向けのユーザーエンド製品のほぼ中間です。なぜなら、多くの人々が新しい機能を開発して新しい機能を実現し、親切な人はまだ見ていません。したがって、私の場合、少なくともSDKの場合はC89を優先することは実際には非常に単純な決定でした。

私はあなたがあなたの周りのコンパイラを見て、あなたのターゲット人口統計を把握しようとする必要があると思います。Windows用のプラグインアーキテクチャを開発していない場合、または組み込みプログラミングを行っていない場合、または最も広範囲のコンパイラや言語で使用できるソフトウェア開発キットを構築しようとしている場合、C99 +離れて。また、C99以降でどれだけ生産性が向上するかを検討することもできます。データが収まる場合はスタックを使用し、それ以外の場合はヒープを使用するための単純で十分な方法に依存しているため、VLAのようなものからそれほど利益を得ることはありません。

しかし、MSVCのような人気のあるコンパイラから他の言語のFFIに遅れをとっているものはたくさんあります。これらは、dylibから直接C関数をインポートして呼び出すことができるという意味でクールですが、回。したがって、ドメインに応じて、ある種の美学のために古いものや標準化されたものを単に好むことよりも、考慮すべきより実用的なビジネス上の事柄があります。