問題タブ [c99]

printf の man ページを調べていたところ、何かが思い浮かびました。比較的簡単な質問に答えることができる「言語弁護士」がここにいるかどうか疑問に思っていました:-P.

したがって、「t」修飾子は次のように定義されます

次の整数変換は、ptrdiff_t 引数に対応します。

これを符号なし整数変換と組み合わせるとどうなるでしょうか? 明らかに、o、u、x、X はすべて符号なしの値として解釈されることを意図していますが、d と i は符号付きです。

同様にsize_t、.ssize_tptrdiff_t

実際には、型の署名されていないバージョンは署名されたバージョンと同じ量のスペースを占有するため、悪いことは何も起こりません。したがって、適切なバイト数がスタックからポップされます。

したがって、「悪い」ことは何も起こりません。実際には、「」を除くすべてのテスト対象の期待値が出力されますINT_MIN( sizeof(int) == sizeof(ptrdiff_t).

版画

32 ビット システムで。

規格はこれについて意見を持っていますか? 答えは「未定義の動作」になると思います。しかし、私は尋ねると思いました;）。

いくつかのドキュメントと質問/回答を閲覧していて、それが言及されているのを見ました。簡単な説明を読みましたが、それは基本的に、ポインターが他の場所を指すために使用されないというプログラマーからの約束であると述べています。

これを実際に使用する価値がある現実的なケースを誰かが提供できますか?

私は今、プロジェクトをコンパイルしようとし-std=c99ていますが、今のところ理解できないエラーに直面しています。この行：

C99 でのみ次のエラーが表示されます。

これが何を意味するのかを理解するのに役立つ手がかりは大歓迎です。私はこの行を書いていません。また、その目的が何であるかを理解することもできません。

私と他の多くの人は、RAII などを使用して、C++ で安全でないメモリ操作をラップするためにスマート ポインターを使用して大きな成功を収めたと思います。ただし、デストラクタ、クラス、演算子のオーバーロードなどがある場合は、メモリ管理をラップする方が簡単に実装できます。

生のC99で書いている人にとって、安全なメモリ管理を支援するためにどこを指摘できますか?

ありがとう。

大まかな理解はしていますが、restrictいくつかの細かい点を明確にしたいと思っています。あるバッファから null で終わる文字列を読み取り、別のバッファに URL エンコードされたバージョンを書き出す関数があります。関数には次のシグネチャがあります (現在は なしrestrict):

unencoded私のヌル終了ソース文字列です。encoded宛先バッファはandで表されますencodedEnd。ここで、 はバッファ内encodedの最初のものを指し、バッファの後の最初の charを指します。つまり、関数はsを書き込みますが、 が指す場所は含みません。これは基本的な/イテレータです。 C++ STL 規則に精通している場合は、ペアにしてください。charencodedEndcharencodedEndbeginend

この関数に追加restrictする場合、最初の 2 つのパラメーターにのみ適用する必要があります。

または、3つのパラメーターすべてに追加することで理解できない利点がありますか?

入力バッファーと出力バッファーを作成するとrestrict、それらがオーバーラップしていないことをコンパイラーが認識するのに役立つことがわかります。しかし、最後のパラメーター ,encodedEndは出力バッファーの末尾をマークするためにのみ使用されるため、restrictここでコンパイラーにとって実際には何の助けにもならないと思います (ただし、不要なノイズを追加する以外は、害はないと思いますが)関数宣言に）。

C99 に存在するいくつかの数学関数を使用するコードがありますが、VS2005 に付属する math.h または cmath では定義されていません。VS2005 と互換性のある C99 の実装をどこで入手できますか?

このコードを考慮すると、VC9はエイリアシングを検出しません：

明らかな修正は、一時的なものを使用することです：

これは標準的な動作ですか？私は、コンパイラーが、そのように言われない限り、両方のポインターがおそらくエイリアス化されていると想定することを期待していました。

次の大まかな署名を持つコードがあります。

ほとんどのコンパイラは、pArray の代入を喜んで飲み込みますが、nElements の代入では窒息します。この矛盾は私を混乱させます、そして私は悟りたいです。

const 整数を割り当てることができないことを受け入れるのに問題はありませんが、const-pointer-to-const に対して期待どおりに機能するのはなぜですか?

迅速かつ安価な修正は、const 修飾子を削除することですが、ループ内のコードの多くがマクロ化されているため、微妙なバグが発生する可能性があります (私は一度それに噛まれました)。上記をどのように再構成して、一定の要素カウンターを許可しますか?

私がオフィスで最近参加したコーディング スタイルのプレゼンテーションでは、変数を定義するときに変数を (既定値に) 割り当てるべきではないと主張していました。代わりに、使用する直前にデフォルト値を割り当てる必要があります。だから、次のようなもの

眉をひそめるべきです。

明らかに、「int」の例は単純化されていますが、ポインターなどの他の型についても同じことが言えます。

さらに、C99 互換コンパイラが上記のケースで警告を出すようになったことも言及されました。

上記のアプローチは、構造体に対してのみ有用に見えます。つまり、使用前にのみ memset します。これは、構造体がエラー レッグでのみ使用される (または埋められる) 場合に効率的です。

他のすべてのケースでは、コードの作成中および保守中に初期化されていないポインターが原因で多くのバグに遭遇したため、デフォルト値を定義して割り当てることは賢明な方法であることがわかりました。さらに、コンストラクターを介した C++ も同じアプローチ、つまり定義と代入を提唱していると思います。

なぜ（もし）C99標準が定義と割り当てを好まないのか疑問に思っています。コーディング スタイルのプレゼンテーションで推奨されていることを実行する上で、それらはかなりのメリットがありますか?

私が書いているいくつかの低レベルのコードに問題があります。オブジェクトを揮発性として使用する必要がありますが、(再利用性の理由から) 型を揮発性として宣言する必要があるとは限りません。ただし、次のセグメントで詳しく説明するように、構造体の修飾バリアントへのポインターを定義できます。

これで foo は事実上、次の型のオブジェクトへのポインターになります。

volatile はすべての構造体メンバーに適用されるためです。ここで私の質問は、オブジェクトに別のオブジェクトへのポインターが含まれている場合、揮発性はどのように適用されるのですか?

x の揮発性インスタンスへのポインターは、次のように扱います。

またはとして：

私はC標準を読みましたが、これに関してはあまり明確ではなく、複数の方法で言葉遣いを簡単に解釈できます.