問題タブ [c11]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c - _Alignasとの構造体メンバーの位置合わせ
私は次のことについて疑問に思っていました:_Alignas
C11の新しいアライメント指定子は構造体メンバーに適用できますか?
私はいつもそれだけを想定していましたが、N1570の公開ドラフトをよく読んだことは、アライメント指定子が指定子修飾子リストに表示されないことを示しているようです。 。_Alignas
文法を数回読みましたが、構造体のメンバー宣言でどのように許可されるのか理解できません。
ただし、 (§6.7.5)の段落で「[...]の宣言でアライメント属性を指定してはならない」と述べられているため、この規格の目的は
_Alignas
構造体のメンバーに適用できるようにすることであるように思われます。_Alignas
ビットフィールド」。「ビットフィールド」という用語が§6.7.2.1で構造体メンバーとして定義されていることを考えると(正確な言い回し:「そのようなメンバーはビットフィールドと呼ばれます」)、私は常にその文を暗黙的にアラインメント指定子を意味すると解釈していました非ビットフィールドメンバーに許可されます。
既存の実装と照合すると、Clang3.0とGCC4.7の両方が、_Alignas
文句を言わずに構造体メンバーをサポートしていることがわかります(with -pedantic
)。Parser::ParseSpecifierQualifierList
Clangソースコードは、アライメント指定子を許可することを除いて、N1570と同じ文法を再現します。ただし、この関数にはTODO要素が含まれています。
GCC Cパーサーコードは類似しているように見えます。つまり、標準の文法を引用していても、指定子-修飾子リストでアライメント指定子を使用できます。
また、既知の欠陥のリスト、およびcomp.lang.cとcomp.std.cをチェックして、トピックがそこで提起されているかどうかを確認しましたが、そうではないようです。したがって、私の質問:構造体のメンバーでアライメント指定子が許可されることになっていますか?
編集:関連する文法規則は次のとおりです。
c++ - C11 または C++11 に ASCII または UTF-8 文字リテラルがないのはなぜですか?
UTF-8 文字列リテラルがあるのに、C11 または C++11 に UTF-8 文字リテラルがないのはなぜですか? 一般的に言えば、文字リテラルは、単一オクテットの UTF-8 コード ポイントと同一の単一の ASCII 文字を表すことを理解していますが、C も C++ もエンコーディングが ASCII である必要があるとは言いません。
基本的に、標準的な権利を読むと'0'
、整数 0x30 を表す保証はありませu8"0"
んが、char シーケンス 0x30 0x00 を表す必要があります。
編集:
すべての UTF-8 コード ポイントが 1 つの文字に収まるわけではないことは承知しています。このようなリテラルは、単一オクテットのコード ポイント (別名、ASCII) に対してのみ有用であるため、「ASCII 文字リテラル」と呼ぶ方が適切であると思われるため、問題は依然として残っています。UTF-8 文字列リテラルがあるため、質問を UTF-8 で組み立てることを選択しました。移植可能な ASCII 値の保証を想像できる唯一の方法は、文字ごとに定数を記述することです。これは、128 個しかないことを考えるとそれほど悪くはありませんが、それでも...
gcc - ビットフィールドの GCC 実装のバグ
C11 での作業、次の構造体:
unsigned
4 ビットが使用される (4 バイト)として GCC によってレイアウトされ、その後_Bool
に 1 ビットが使用される (4 バイト) が続き、合計サイズは 8 バイトになります。
C99 と C11 では_Bool
、ビット フィールド メンバとして明確に許可されていることに注意してください。C11 標準 (およびおそらく C99 も) は、§6.7.2.1 '構造体および共用体指定子' ¶11 の下で次のように述べています。
実装では、ビットフィールドを保持するのに十分な大きさのアドレス可能なストレージユニットを割り当てることができます。十分なスペースが残っている場合、構造内の別のビットフィールドの直後に続くビットフィールドは、同じユニットの隣接するビットにパックされます。
したがって、b
上記のメンバーは、メンバーに割り当てられたストレージユニットにパックされているはずでありa
、合計サイズが 4 バイトの構造体になると思います。
GCC は正しく動作し、2 つのメンバーに同じ型を使用する場合、または一方がunsigned
で他方が である場合にパッキングが行われますsigned
が、型unsigned
と_Bool
は GCC によって区別されすぎて正しく処理できないと見なされているようです。
誰かが標準の私の解釈を確認できますか?これは実際に GCC のバグです?
また、回避策 (コンパイラ スイッチ、プラグマなど) にも興味があり__attribute__
ます。
私は gcc 4.7.0 を使用して-std=c11
います (ただし、他の設定は同じ動作を示します)。
c - P99 と C99 対 C11
多分私はP99ライブラリの使用を誤解していますが、エミュレーターである以上のものがあれば、C11 (主にマルチスレッドに関する懸念) よりもどのような利点がありますか。
スピード?効率?
それとも後方互換?
c - ユニオンを介した型のパンニングはC99で指定されていませんか?また、C11で指定されていますか?
Stack Overflowの質問に対するいくつかの回答floatのIEEE単精度ビットを取得するには、型のパンニングの構造を使用することをお勧めしますunion
(例:aのビットをafloat
に変換するuint32_t
)。
ただし、uint32_t
組合員の価値は、C99標準(少なくともドラフトn1124)に従って指定されていないようです。ここで、セクション6.2.6.1.7には次のように記載されています。
共用体型のオブジェクトのメンバーに値が格納されている場合、そのメンバーに対応していないが他のメンバーに対応しているオブジェクト表現のバイトは、指定されていない値を取ります。
C11 n1570ドラフトの少なくとも1つの脚注は、これがもはや当てはまらないことを示唆しているようです(6.5.2.3の脚注95を参照)。
共用体オブジェクトの内容を読み取るために使用されたメンバーが、オブジェクトに値を格納するために最後に使用されたメンバーと同じでない場合、値のオブジェクト表現の適切な部分は、新しいタイプのオブジェクト表現として再解釈されます。 6.2.6で説明されています(「型のパンニング」と呼ばれることもあるプロセス)。これはトラップ表現である可能性があります。
ただし、セクション6.2.6.1.7のテキストは、C99ドラフトでもC11ドラフトでも同じです。
この動作は実際にはC99では指定されていませんか?C11で指定されていますか?ほとんどのコンパイラがこれをサポートしているように見えますが、それが標準で指定されているのか、それとも非常に一般的な拡張機能であるのかを知っておくと便利です。
c - -std = c1xが使用されているかどうかを__STDC_VERSION__を使用して確認するにはどうすればよいですか?
C11の場合、テストできることを知ってい#if(__STDC_VERSION >= 20112L)
ます。しかし、-std=c1x
どのマクロや値をテストする必要がありますか?
この規格の命名法は何ですか?または、もしあれば、非公式の名前かもしれません。これが明確であることを願っています。前もって感謝します。
c - 配列添え字演算子について
C11標準からの引用:
アレイのサブスクライブ(§6.5.2.1)
添え字演算子の定義は、
[]
とE1[E2]
同じです(*((E1)+(E2)))
。
なぜ括弧がE1
必要なのか(C89標準では欠落していた)、つまり、どの式が(*(E1+(E2)))
異なる可能性があるのかを知りたいのですが(*((E1)+(E2)))
?
c++ - 変数からの単純な読み取りと比較して、memory_order_relaxedを使用したatomic_load()は追加のオーバーヘッドを導入しますか?
「ネイティブ」CPU インテグラルの追加オーバーヘッドの理由はわかりませんが、間違っている可能性があるため、コミュニティの意見を聞きたいと思います
私の本当の問題は、比較的めったに変更されないが、頻繁に読み取られるある種のリンクされたリストに関するものです (典型的な RCU の使用例に似ています)。アイデアは、読み取り専用操作に 2 つのアクセス モードを提供することです。最初のモードは、構造が現在変更されている場合 (本格的なロック フリー アルゴリズム) に使用され、2 番目の軽量モードは、「落ち着いた」場合 (非アトミック リスト トラバーサル) に使用されます。2 番目の (軽量) ケースでは、memory_order_relaxed でアトミック ロードを使用しますが、コストが高すぎる場合は、いくつかの回避策を実行する必要があります (非アトミック変数にアトミック値をキャッシュするか、提案された何らかの方法でエミュレートします memory_order_nonatomic http ://www.open-std.org/jtc1/sc22/wg14/www/docs/n1446.htmなど)
答えはアトミック実装(およびCPU)に依存することを理解していますが、実装が合理的に動作することを願っています:)
c++ - C と C++ の特定の標準の違い
C++11 と C99 のすべての違いはどこで確認できますか?
C89/C90がベースのC++98やC++03だと思います。それらの間に違いはありますか?C++11 と C99 はどうですか? C99 の一部の機能は C++11 に追加されましたが、他の機能 (複合リテラル、VLA など) は追加されませんでした。この変更の完全なリストを見ることはできますか?
c - C11とC99の一時オブジェクトの寿命
C99とC11の間の変更につながったメモを解読しようとしています。そのノートで提案された変更は、C11の6.2.4:8になりました。
構造体または共用体が配列型のメンバー(再帰的に、含まれるすべての構造体および共用体のメンバーを含む)を含む、構造体または共用体タイプの非左辺式は、自動保存期間と一時的な存続期間を持つオブジェクトを参照します。その存続期間は、式が評価されたときに始まり、その初期値は式の値です。含まれている完全な式または完全な宣言子の評価が終了すると、その存続期間は終了します。一時的な有効期間でオブジェクトを変更しようとすると、未定義の動作が発生します。
変更が必要な理由を理解しています(いくつかの議論はここにあります。議論はC11の前に戻っていることに注意してください)。しかし、私が理解していないのは、クラーク・ネルソンが彼のメモを書いたときに行った副次的な発言です。
このアプローチでは、C99で準拠していたこのような例が、非準拠であるとさらに宣言されていることに注意してください。
この例がC11で不適合である理由を理解しています。私が特に理解していないのは、C99でどのように準拠しているかです。そして、それがC99で定義されている場合、それは何をすることになっているのでしょうか、ダングリングポインタの値を明確に出力しますか?