新しいCプロジェクトは、非常に古いC標準（> 20年、つまりC89）をいつターゲットにする必要がありますか？
非常に古いC標準（通常はC89）をターゲットとする、比較的新しい主要なオープンソースCプロジェクトがときどき見られます。例はsystemdです。これらのプロジェクトは実権を握っているインテリジェントな人々を持っているので、おそらく彼らは私が知らないこの決定の背後に良い理論的根拠を持っています。疑問の余地はさておき、その論理的根拠は「古く、標準化されている方が常に移植性が高く、優れている」と思われますが、論理的な結論は、FORTRANがCよりも優れており、COBOLはFORTRANよりも優れているということです。
新しいCプロジェクトが非常に古いC標準をターゲットにすることが正当化されるのはいつ、なぜですか。
ユーザーのシステムがCコンパイラを絶対に更新してはならないが、それ以外の場合は新しいソフトウェアを自由にインストールできるシナリオは想像できません。たとえば、DebianのLTSバージョンには、C99と一部のC11をサポートするgcc 4.6パッケージがあります。奇妙なシナリオが存在する必要があると思いますし、systemdのようなプログラムはそれらのユーザーをターゲットにしています。
私が想像できる最も合理的なユースケースは、ユーザーがonly C89コンパイラーが利用可能なエキゾチックなアーキテクチャーを持っていると予想されるが、新しいソフトウェアを完全にインストールする用意がある場合です。命令セットアーキテクチャの多様性の低下を考えると、それは過度に仮説的なシナリオのように見えますが、私にはわかりません。
...ばかげている "古いものと標準化されたものは常によりポータブルでより良い"です...
betterになると、そのステートメントはばかげたものになりました。これは完全に主観的なものです。あなたが行った最後の交流会の半分の人がそれを使っていたので、プロジェクトの言語と標準を選択しませんでした。あなたが解決しようとしている問題を研究して理解し、それが仕事に適したツールであると判断したので、それを選びます。
一般的に、標準については、移植性のためにいくつかのプロジェクトで作成する必要がある場合があり、それは古いものを選択することにはいくつかの利点があります。これは、ライブラリを製品として開発しているときに特に当てはまります。これは、他者の目的を達成するための手段です。あなたがやりたい最後のことはあなたがまだ会っていない顧客が利用できないかもしれないコンパイラを必要とするのであなたが売ることができない何かを書くことです。埋め込まれた世界についてのフィリップ・ケンドールのコメントはその場にあります。人々はまだ古い安定したプラットフォーム用の新しいコードを書かなければならないか、追加の機能の恩恵を受けず最新のコンパイラーを入手できないプラットフォームのどちらかが原因で、多くのことが起こっています。プロジェクトのあらゆる側面を完全に管理している場合、環境がサポートできる最新の標準を使用しない理由はありません。
特にCの場合、最新の標準に準拠する代わりに何が得られるかという問題があります。 K＆RからC89への移行は大きな変更であり、古いコードをクリーンアップするために多くの努力を必要としましたが、最終的には多くのことを行いました。 C99での変更 と C11 は、比較的小さいものであり、最近開発されたCのほとんどは、新機能を使用しないため、C89をパスします。 1行のコメントをサポートし、ネイティブのブールデータ型を持ち、可変長配列を実行できるため、C89を超えるC99を強制することは正しいことだと主張するのは困難です。コメントとブール値には醜い回避策があり、VLAは他のわずかに効率の悪い方法で処理できます。 C11はVLAをオプションに降格しましたが、実装に目立つように見える場合は、それが古いC99を選択する正当な理由になる可能性があります。
幅広いプラットフォームにわたる移植性が重要な場合。これには、時代遅れのプラットフォームや、最小限のコンパイラしか利用できない多くの組み込みプロセッサが含まれる場合があります。
また、C89が「最も低い共通項」であるという感覚もあります。これは最初の適切に標準化されたバージョンであり、今日使用されているほとんどすべてのコンパイラは、C89のスーパーセットを実装していると想定できます。
また、Microsoft Visual C++は、C++標準に追いつくのは比較的良かったものの、CモードのときにC89に長時間留まっているという問題もあります。したがって、最新のVisual Studioを使用していないユーザーはC89に限定される可能性があります。
主にマイクロソフトのために、まだ疑似C89コード（完全にC99に準拠していない）を書いていることを認めなければなりません。私はWindows向けのMSVCに大きく依存していますが、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に対するMicrosoftのスタンスを考えると、C99にはるかに準拠しているとは思えません） 。
そして、残念なことに、まだ完全にC99に準拠していない、優れたオプティマイザとデバッガで実際に非常に優れた新しいコンパイラがまだあります。もちろん、そうでなければ、私はC11のあちこちを飛び越えます。
プラグインおよびMSVCとのソース互換性に加えて、他の言語との相互運用性もあります。他のいくつかの言語はFFIを通じてSDKを使用し、それらのFFIのいくつかはC89のみを理解します。彼らはdylibから関数をインポートするときの単純な例としてboolまたは_Boolを理解せず、intだけを理解するかもしれません。
はい、賛成の議論は移植性ですが、問題は、C89コンパイラーしか使用できないが、ソフトウェアの新しいディストリビューションをコンパイルしている非仮想システムが実際にあるかどうかです。つまり、新しいCプロジェクトを開始した場合、C89に準拠することで潜在的なユーザー数を増やすことができるかどうかをどのように判断すればよいですか？
これに気付いたばかりですが、Blrflをエコーしているようです。私の場合、C99とC11を使用することによる生産性の向上はそれほど大きくありません。特に、私が取り組んでいる製品は、Windows側で圧倒的に最大の市場シェアを有しており、平均的なユーザーは、多くのサードパーティプラグインを購入してダウンロードします。私が取り組んでいる製品の種類は、プログラマー/スクリプトの開発環境とアーティストのユーザーエンド製品のほぼ中間です。なぜなら、多くの人が新しい機能を開発して新しい機能を実現し、特殊な効果を達成したいからです。親切な人はまだ見ていない。したがって、私の場合、少なくともSDKでC89を採用するのは実際には非常に簡単な決定でした。
私はあなたがあなたの周りのコンパイラをちょっと見て、あなたのターゲットの人口統計を理解しようとする必要があると思います。 Windowsのプラグインアーキテクチャを開発していない場合、または組み込みプログラミングを行っていない場合、または幅広いコンパイラや言語で使用できるソフトウェア開発キットを構築しようとしている場合は、C99 +への到達が容易になります。離れて。また、C99以降の生産性をどの程度向上させるかについても検討してください。データが収まる場合はスタックを使用し、それ以外の場合はヒープを使用するための単純な十分な方法に依存しているため、VLAなどのメリットはあまりありません。
しかし、MSVCのような一般的なコンパイラから他の言語のFFIに遅れをとっていることがたくさんありますが、dylibから直接C関数をインポートして呼び出すことができるという点で優れていますが、回。したがって、ドメインによっては、単に古いものを優先して、ある種の美的要素のために標準化するよりも、検討する必要のある実際的なビジネス事項がたくさんあります。