問題タブ [undefined-behavior]

C ++ FAQのこの段落では、構成の使用法delete thisについて説明します。4つの制限がリストされています。

制限1から3はかなり合理的に見えます。しかし、なぜ制限4があるので、「調べたり、別のポインターと比較したり、NULLと比較したり、印刷したり、キャストしたり、何かをしたりしてはならない」のでしょうか。

つまりthis、もう1つの指針です。なぜreinterpret_castそれをintまたは呼び出しprintf()てその値を出力できないのですか？

このコードは 29 を出力すると誰かが私に言いました。それはなぜですか?

まず第一に、delete割り当てられたものに対して使用するnew[]と、C++ 標準に従って未定義の動作になります。

Visual C++ 7 では、このようなペアリングは 2 つの結果のいずれかにつながる可能性があります。

new[] された型に自明なコンストラクタとデストラクタがある場合、VC++ はそのブロックnewの代わりに単純にnew[]使用しdelete、そのブロックに対して使用すると正常に動作します- new「メモリの割り当て」をdelete呼び出すだけで、「メモリの解放」を呼び出すだけです。

new[] された型に自明でないコンストラクタまたはデストラクタがある場合、上記のトリックは実行できません。VC++7 は正確に正しい数のデストラクタを呼び出す必要があります。そのため、配列の先頭size_tに要素数を格納します。によって返されるアドレスはnew[]、ブロックの先頭ではなく、最初の要素を指すようになりました。したがって、delete使用されている場合、最初の要素のデストラクタのみが呼び出され、「メモリの割り当て」によって返されたアドレスとは異なるアドレスで「メモリの解放」が呼び出されます。腐敗。

しかし、あちこちで、deleteafterを使用new[]するとメモリ リークが発生するという誤ったステートメントを読むことができます。デストラクタが最初の要素に対してのみ呼び出され、おそらく呼び出されなかったデストラクタがヒープに割り当てられたサブオブジェクトを解放しなかったという事実よりも、ヒープ破損のサイズが重要であると思います。

deleteafterを使用new[]すると、一部の C++ 実装でメモリ リークが発生する可能性があります。

C ++では、スタック割り当てオブジェクトを宣言できますconst。

その後、そのようなオブジェクトで非constメソッドを呼び出そうとすると、未定義の動作になります。

ヒープに割り当てられたオブジェクトがconst同じ結果になる可能性はありますか？つまり、次の可能性があります。

未定義動作でもありますか？

クラスシングルブロックのインスタンスとして各ブロックを使用して、シンプルで機能するテトリスゲームを作成しました。

完全な行をスキャンし、ブロックのリンクリストを実行して、関連するブロックを削除し、->次のポインターを再割り当てする関数があります。

ゲームは動作し、ブロックは正しく削除され、すべてが想定どおりに機能します。ただし、検査すると、削除されたデータのランダムなビットにアクセスできます。

削除後に削除されたシングルブロックの「x」値をそれぞれprintfすると、ランダムなガベージを返すもの（削除を確認するもの）と222を返すものがあり、デストラクタが呼び出されても、データは実際には削除されていないことがわかります。ヒープ。多くの同一の試行は、適切に削除されないのは常に同じ特定のブロックであることを示しています。

結果：

予想外のデータにアクセスできるのでしょうか？

これが少し長蛇の列になっている場合は申し訳ありません。

次のコードがあるとします。

以下は定義された動作を使用していますか?

クラスレジストリを使用しているので質問しています。直接変更しないfので、それを作成するといいのですconstが、後でfレジストリによって間接的に変更されます。

編集:定義された動作とは、つまり、オブジェクトは一度しか書き込めない特別なメモリ位置に配置されているということですか? 少なくとも C++1x の constexpr までは、読み取り専用メモリは問題外です。たとえば、定数プリミティブ型は (多くの場合) 読み取り専用メモリに配置され、const_castそれに対して a を実行すると、次のような未定義の動作が発生する可能性があります。

http://www.cppreference.com/wiki/stl/deque/insertを参照として使用して、特定の場所で両端キューに値を挿入していました。

たとえば、deque A が次の場合:

d を指すイテレータを使用すると、次のことができます。

iter はまだ d を指しています。ただし、 iter が g を指す場合、最後の要素:

しかし iter は f を指すようになりました!!

私の現在の回避策は次のとおりです。

私はこれをもう一度テストしたことはありません。バグを追跡するのに非常に多くの時間を費やして、すべての場所のstlでinsert()の一貫性のない動作を発見するのは面倒でした。

最後に、他の場所と比較して、insert() の動作が異なるのはなぜですか? それとも私が何か間違ったことをしたのですか？

多くの無邪気に見えるものはC++では未定義の動作であることがわかります。たとえば、null以外のポインタを出力すると、そのポインタ値は未定義の動作になりdeleteます。

現在、メモリリークは間違いなく悪いです。しかし、それらはどのようなクラスの状況ですか？定義済み、未定義、または他のどのクラスの動作ですか？

次のコードを検討してください。

コードが有効かどうかについて、地域コミュニティで議論がありました（名前を言うことになっていますか？）。ある男は、それが違反しているのでUBを呼び出すと言っていました

C ++標準（$ 5.7 / 5 [expr.add]）

「ポインタオペランドと結果の両方が同じ配列オブジェクトの要素を指している場合、または配列オブジェクトの最後の要素を1つ過ぎている場合、評価はオーバーフローを生成しません。それ以外の場合、動作は未定義です。」

しかし、コードに問題はありません。コードは私にとって完全に問題ありません。

だから、私はこのコードが有効かどうか知りたいだけですか？私は何かが足りないのですか？

私の読書から理解しているように、 undefined-behavior は、コンパイル時にいくつかの同一でない代替手段をコンパイラに残した結果です。ただし、厳密なコーディング慣行に従う場合 (各代入と各等号を別々のステートメントに入れる、適切なデバッグとコメントを付けるなど)、未定義のソースを見つける際に重大な問題を引き起こすべきではないということではないでしょうか? -行動。

さらに、発生するエラーごとに、コードを特定すると、その特定のステートメントの代わりにどのステートメントを使用できるかを知る必要がありますね。

編集: 書くつもりのないコードを書いた場所には興味がありません。私は、数学的論理によって正しいコードが機能しない例に興味があります。

また、「優れたコーディング プラクティス」とは、数行ごとの強力な有益なコメント、適切なインデント、および定期的なデバッグ ダンプであると考えています。