C 2011で可変長配列がオプションになったのはなぜですか?


12

VLAがC 1999で導入されたとき、私はそれが言語の大きな革新だと思っていました。しかし、C 2011でオプションになったことを知ったので、ステータスの変化につながったのはなぜか、そしてそれが機能が実際に陳腐化に向かう​​ことを意味するのかどうか疑問に思っています。もしそうなら、それを置き換えると考えられている動的にサイズ変更されたデータの自動管理の同等の概念がありますか?

C 2011の理論的文書を見つけようとしましたが、まだ公開されていないようです。


養子縁組の欠如?
ライアンライヒ

@RyanReich:おそらく、ベンダーからの抵抗はなぜですか?
jxh

回答:


8

「いくつかの小さなコンパイラはVLAなしでC11に準拠できる必要があるため、オプションにする必要がある」から「そもそも間違いだった」まで、さまざまな言い伝えを聞いています。しかし、これに対する真の明確な答えは一度もありません。最終的に、私は誰もが実際にそれを持っているとは思わない(理由があると仮定して-そして期待している-)が決して開示されなかった(私の古い検索に関する限り)。


国際標準の理論的根拠の第4章(13ページ)-プログラミング言語-C 5.10(2003)から

受け入れるプログラムの観点から適合実装を定義することにより、規格は適合実装の一部として広範なクラスの拡張機能への扉を開いたままにします。準拠するホスト型と準拠する自立型実装の両方を定義することにより、標準はCを使用して、オペレーティングシステムやROMベースのアプリケーション、さらに従来のホスト型アプリケーションなどのプログラムを作成することを認識します。C89委員会は、レベルが多すぎると標準の有効性が薄められると強く感じたため、この2レベルのスキームを超えて、Cの追加のサブセットは定義されていません

強調鉱山。この決定は独自の根拠に反することに注意してください。しかし、別のことがオプションになりました。これで__STDC_NO_VLA__、VLAのサポートを取得できます。それは非常に奇妙な決定です。


@jxhそれさえ見ませんでした。それを指摘してくれてありがとう、より明確で曖昧さの少ない言葉遣いに変更されました。モチーフはいくつかの文脈で動機と目標の同義語として見てきましたが、それは芸術的なシナリオでのみ一般的だと思います。
ベルナルドスルツバッハ

2レベルのスキームしか持たないことの問題は、広くサポートされているが完全にはサポートされていない多くの便利な機能と保証があり、ある種のプログラムを他の方法で可能な場合よりもはるかに効率的に記述できることです。このような機能の可用性をテストする標準的な手段がないため、多くの分野で実際的なプログラムの大部分ではないにしても、かなりの部分が標準に含まれる保証を超える保証を利用する必要があり、特定かどうかの確実性
...-supercat

...プログラムは特定の実装で動作します。さまざまなオプション機能を定義し、どの実装がサポートするか拒否するかを保証することで(コンパイルを拒否することにより)、要件を適切に指定するプログラムがプラットフォームで正しく動作するかどうかをテストするための素敵で簡単な標準的な方法が可能になります:tryそれを構築します。ビルドすれば機能します。そうでない場合は、明らかにそうではありません。成功したビルドが成功した操作を保証することを保証できるプログラムの割合を増やす
...-supercat

...標準が要求する以上の機能や保証の恩恵を受けないプログラムのごく一部を処理できるコンパイラの数を単に最大化するよりもはるかに価値があるように思われます。
-supercat

4

私が公開委員会のドキュメント(特にN1395)から判断できる限り、VLAを(複雑な算術演算とスレッド化とともに)オプションにする主な理由の1つは、小さな組み込みプロセッサ用の適合Cコンパイラを作成できるようにすることでした。

傾向としては、組み込みシステムをターゲットとするコンパイラベンダーは、顧客が求めていなかった大きな機能が導入されたため、C90標準にとどまっています。


多くの場合、「除外するように求めていました」。これらの機能を有効にしたときにRAMフットプリントの変化を見ると、なぜそれを望まないのかが明らかになります。プロセッサのコストを2倍にすることができ、これはシステムの最も高価な部分になる可能性があります。
Ⴖuі16年

1
@JerryCoffin:はい。ただし、sizeof()が実際に配列で使用される場合にのみコードが生成されます。コンパイラは、正しいコードを生成できるように情報を追跡する必要がありますが、その情報をVLAのメモリ内表現に埋め込む必要はありません。
jxh

2
@jxh:当初想定されていたように、独立型およびホスト型の実装は同じコア言語を使用していました。違いはライブラリに限定されていました。VLAの場合、言語自体に違いがあり(少なくとも一部のベンダーは、小規模な組み込みシステムには実際には適さないと感じていました)。サイズの埋め込みに関する限り:いいえ、おそらく絶対に必要というわけではありませんが、最も簡単な方法かもしれません(たとえば、サイズのストレージの数バイトは、それを計算するために多くのコードのバイトを避けるかもしれません)。
ジェリーCo

1
@supercat:Cライブラリの機能をチェリーピッキングするロジックを見ることができますが、言語機能を「オプション」にすることは、マルチプラットフォームのCコードを作成しようとする人にとって明らかに役に立たないようです。これは、使用さ Cは、それが簡単に別のコンパイラと異なるハードウェアプラットフォームにリターゲットすることができ、プログラミング、金属のシステムに近いため当然の選択であったとします。さて、それはそれほど明白ではありません。
jxh

1
@supercat:スタックの爆撃はVLAに固有のものではありません。異常に大きな自動オブジェクトまたは抑制されていない関数呼び出しスタックにも同様の問題があります。これらのケースで障害を検出する手段が標準で定義されている場合、VLAでも機能する可能性があります。オプションという点では、複数のベンダーのコンパイラを使用して複数のプラットフォームで動作する必要がある新しいプロジェクトの新しいCコードで新しいC機能を使用することを主張するのが難しくなります。
jxh
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.