C11のkeywordsいキーワードはなぜですか?


15

現在、C11仕様のドラフトを読んでいます。新しく導入されたキーワード:_Bool, _Alignof, _Atomicのような標準の予約キーワードではなく、すべてカスタム拡張のように感じstruct, union, intます。

標準は基本的に標準化された拡張機能で構成されていることを理解しています...しかし、それでもひどいです!すぐに__Long_Long_Reallylong_Integer_MSVC_2020_t規格に忍び寄ってしまうかもしれません!

非標準コードの後方互換性がキーワードの新しいスタイルの唯一の理由ですか?


2
ああ、私はそのような本当に長い型については心配しません。_、az、AZ、および0-9の文字と数字の組み合わせの数は、おそらく短くて覚えにくいことを意味します。
ニール

2
各キーワードの見栄えの良い同義語は、関連する標準ライブラリヘッダーファイルで定義されることがよくあります。たとえば、C11実装の<stdbool.h>ヘッダーファイルには、などのプリプロセッサマクロを含める必要があります#define bool _Bool。これは後方互換性を保持するため、適切なソリューションですが、新しいヘッダーファイルを含む新しいコードでより魅力的な構文を使用できます。
andrew.punnett

回答:


20

完全に標準的なコードとの後方互換性がより重要な理由だと思います。

以前のコードで正当な識別子として使用された可能性のあるキーワードを追加すると、特に複雑な解析ルールを持つ言語であるCで、微妙なエラーが発生する可能性があります。

これらの識別子がどこかでパブリックインターフェイスとして使用された場合、Cをまったく使用せず、RubyやPythonなどからライブラリを呼び出す可能性のある、そのような不幸なライブラリのすべてのユーザーに苦痛を与えます。

そのため、新しいキーワードは見栄えのする言葉ではなく、ボルトオンハックのように見えますが、ユーザーは別の目的で既に使用する可能性が低くなっています。


問題はC ++ではなくCに関するものであり、問​​題ではないことを指摘しておく必要があります。あなたの答えは、Boolブール値であると広く受け入れられていたが実際にはC標準の一部ではないレガシーコードのカスタムタイプとの競合の使用を避けるために、新しいサポートされたタイプに何かという名前が付けられる理由をカバーしていますので、仮定は安全ではありません作る。
ラムハウンド

1
@Ramhound、私見boolはCの精神にもっとあります。また、私はこの答えに完全に納得していません。また、単語のスタイルを変更すると、標準の単語を一目で認識しにくくなります。
ヴォラック

6
@Vorac:問題はbool、言語に無条件に追加された場合、独自の(完全に正当な)バージョンを持つすべてのプロジェクトがboolコンパイルを停止することです。それは言語改訂の受け入れに深刻な害を与えるでしょう。これが、すべての新しい識別子が予約済みセットから取得される理由です(したがって、で始まります_[capital])。boolそれ自体にも大きな需要があったので、これはのように追加されtypedef _Bool boolました<stdbool.h>
バートヴァンインゲンシェナウ

1
@BartvanIngenSchenau-独自のブール値のtypedefを含まれているものに置き換えるstdbool.hか、独自のtypedefを新しいタイプに更新して、レガシーコードをサポートできます。
ラムハウンド

1
@Ramhound-新しいC11キーワードと競合する変数を持つ人々は、「それを使用しないでください?」新しい言語標準との競合を防ぐために、コンパイルフラグstd = xxxがあります。
スクーター14年

8

アンダースコアと大文字で始まる名前(およびダブルアンダースコアを持つもの)は、以前の標準のコンパイラ/標準ライブラリの実装用に予約されていました。

C89およびC99の予約済み識別子から:

また、実装者用に予約されているのは、アンダースコアで始まるすべての外部識別子と、アンダースコアで始まり、その後に大文字またはアンダースコアが続く他のすべての識別子です。

したがって、理論的には、これらの新しいキーワードは以前に記述されたコードで使用されるべきではなく、それが唯一の理由である可能性が高い単純な名前よりも下位互換性につながります。


4
他の人があなたの声明を迅速に確認できるように、適切な標準セクションを引用し、場合によってはリンクするか、名前を付ける必要があります。これはあなたの答えを改善します。
SpaceTrucker
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.