問題タブ [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.

0 投票する
1 に答える
1518 参照

c - _Alignasとの構造体メンバーの位置合わせ

私は次のことについて疑問に思っていました:_AlignasC11の新しいアライメント指定子は構造体メンバーに適用できますか?

私はいつもそれだけを想定していましたが、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をチェックして、トピックがそこで提起されているかどうかを確認しましたが、そうではないようです。したがって、私の質問:構造体のメンバーでアライメント指定子が許可されることになっていますか?

編集:関連する文法規則は次のとおりです。

0 投票する
5 に答える
5476 参照

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 個しかないことを考えるとそれほど悪くはありませんが、それでも...

0 投票する
2 に答える
3527 参照

gcc - ビットフィールドの GCC 実装のバグ

C11 での作業、次の構造体:

unsigned4 ビットが使用される (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います (ただし、他の設定は同じ動作を示します)。

0 投票する
1 に答える
1340 参照

c - P99 と C99 対 C11

多分私はP99ライブラリの使用を誤解していますが、エミュレーターである以上のものがあれば、C11 (主にマルチスレッドに関する懸念) よりもどのような利点がありますか。

スピード?効率?

それとも後方互換?

0 投票する
4 に答える
10655 参照

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で指定されていますか?ほとんどのコンパイラがこれをサポートしているように見えますが、それが標準で指定されているのか、それとも非常に一般的な拡張機能であるのかを知っておくと便利です。

0 投票する
1 に答える
2421 参照

c - -std = c1xが使用されているかどうかを__STDC_VERSION__を使用して確認するにはどうすればよいですか?

C11の場合、テストできることを知ってい#if(__STDC_VERSION >= 20112L)ます。しかし、-std=c1x

どのマクロや値をテストする必要がありますか?

この規格の命名法は何ですか?または、もしあれば、非公式の名前かもしれません。これが明確であることを願っています。前もって感謝します。

0 投票する
1 に答える
2170 参照

c - 配列添え字演算子について

C11標準からの引用:

アレイのサブスクライブ(§6.5.2.1)

添え字演算子の定義は、[]E1[E2]同じです(*((E1)+(E2)))

なぜ括弧がE1必要なのか(C89標準では欠落していた)、つまり、どの式が(*(E1+(E2)))異なる可能性があるのか​​を知りたいのですが(*((E1)+(E2)))

0 投票する
1 に答える
1006 参照

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)に依存することを理解していますが、実装が合理的に動作することを願っています:)

0 投票する
3 に答える
804 参照

c++ - C と C++ の特定の標準の違い

C++11 と C99 のすべての違いはどこで確認できますか?

C89/C90がベースのC++98やC++03だと思います。それらの間に違いはありますか?C++11 と C99 はどうですか? C99 の一部の機能は C++11 に追加されましたが、他の機能 (複合リテラル、VLA など) は追加されませんでした。この変更の完全なリストを見ることはできますか?

0 投票する
1 に答える
1259 参照

c - C11とC99の一時オブジェクトの寿命

C99とC11の間の変更につながったメモを解読しようとしています。そのノートで提案された変更は、C11の6.2.4:8になりました。

構造体または共用体が配列型のメンバー(再帰的に、含まれるすべての構造体および共用体のメンバーを含む)を含む、構造体または共用体タイプの非左辺式は、自動保存期間と一時的な存続期間を持つオブジェクトを参照します。その存続期間は、式が評価されたときに始まり、その初期値は式の値です。含まれている完全な式または完全な宣言子の評価が終了すると、その存続期間は終了します。一時的な有効期間でオブジェクトを変更しようとすると、未定義の動作が発生します。

変更が必要な理由を理解しています(いくつかの議論はここにあります。議論はC11の前に戻っていることに注意してください)。しかし、私が理解していないのは、クラーク・ネルソンが彼のメモを書いたときに行った副次的な発言です。

このアプローチでは、C99で準拠していたこのような例が、非準拠であるとさらに宣言されていることに注意してください。

この例がC11で不適合である理由を理解しています。私が特に理解していないのは、C99でどのように準拠しているかです。そして、それがC99で定義されている場合、それは何をすることになっているのでしょうか、ダングリングポインタの値を明確に出力しますか?