問題タブ [placement-new]

デバッガーでこれらの行を通過すると、変数 Buffer と BufferPtr の値が表示されます。

これらの値が異なる理由がよくわかりません。私が理解しているように、配置 new は、アドレス 'BufferPtr' で始まるメモリを使用して、割り当てられたメモリのデフォルト コンストラクタを使用して配列要素を初期化し、配列内の最初の要素の最初のバイトへのポインタを返す必要があります。プレースメント new 演算子に渡されたものとまったく同じバイト。

何か間違ったことを理解しましたか、それとも値が異なる理由を教えてもらえますか?

ありがとう！

//編集: わかりました - 問題をさらに調査したところ、より紛らわしい結果が得られました:

デバッガーは、変数に対して次の値を返します。

したがって、明らかに私の汎用スマートポインター クラス matth_ptr と関係があるはずです。

誰が私に何が起こっているのか説明できますか? ありがとう！

ストレージ用の小さなクラスを持つための次のコードがあります。

storage::get()gcc 4.4 は、戻ったときに厳密なエイリアシング規則を破っていることを警告しています。

私の知る限り、私はいかなる規則にも違反していません。私は実際に厳密なエイリアシングに違反していますか、それとも gcc はここでうるさくなっていますか?

そして、厳密なエイリアシングを無効にせずに警告を出さないようにする方法はありますか?

ありがとう

編集：

一方、次の実装では警告が表示されません。

編集：

gcc 4.5 以降は警告を発行しません。つまり、これは厳密なエイリアシング ルールの誤解か、gcc 4.4.x のバグであったようです。

私は、このように独自のメモリ マネージャーで boost shared_ptr を使用しています (例を削除しました。エラーがないことを願っています)。

そして、私はそれを次のように使用しています：

しかし、今、私は気づいています。shared_ptr が onject を削除すると、Deleter::operator() が呼び出され、オブジェクトが削除されます。しかし、デストラクタは呼び出されません...

どうすればこれを変更できますか?

「バリアント型オブジェクト」を実装するために数年間正常に使用しているコードがいくつかあります。つまり、さまざまなタイプの値を保持できるC ++オブジェクトですが、可能なタイプの中で最大のものと同じだけのメモリを（およそ）使用します。このコードは、POD以外のデータ型もサポートしていることを除けば、タグ付き共用体と精神的に似ています。これは、charバッファー、配置new / delete、およびreinterpret_cast<>を使用してこの魔法を実現します。

最近、gcc 4.4.3（-O3と-Wallを使用）でこのコードをコンパイルしようとしましたが、次のような警告がたくさん表示されました。

私が読んだことから、これはgccの新しいオプティマイザが「バギー」コードを生成する可能性があることを示しています。これは明らかに避けたいものです。

以下にコードの「おもちゃバージョン」を貼り付けました。非PODデータ型をサポートしながら、gcc 4.4.3でコードをより安全にするために、コードに対してできることはありますか？最後の手段として、いつでも-fno-strict-aliasingを使用してコードをコンパイルできることは知っていますが、最適化の下で壊れないコードがあると便利なので、そうはしません。

（コードベースにboostまたはC ++ 0Xの依存関係を導入することは避けたいので、boost / C ++ 0Xソリューションは興味深いものですが、もう少し古風なものを好むことに注意してください）

このコードは明らかに機能しないため、違法であるべきだと確信していますが、C++0x FCD では許可されているようです。

おそらく、言語弁護士の1人が、標準がこれをどのように禁止しているかを説明できるでしょう.

配列形式もあります:

これは私が見つけることができた最も近い質問です。

編集:関数への引数を制限する標準の言語が、delete-expressionvoid ::operator delete(void*)のオペランドに意味のある方法で適用されるという引数を購入していません。せいぜい、2 つの間の接続は非常に希薄であり、多くの式がに渡すのに有効でないオペランドとして許可されます。例えば：deletedeletevoid ::operator delete(void*)

void operator delete(void*)これが、ポインタを に渡すことができるかどうかが、同じポインタを のオペランドとして使用できるかどうかに関係がないことを示していることを願っていますdelete。

これが機能しない理由がわかりませんでした。以下Functionは、配置 new によって作成されます。破棄する必要があるかどうかを確認し、破棄する場合はそのデストラクタを手動で呼び出す関数が提供されます。

デストラクタが呼び出されないように見えるテストケースを次に示します。

これを次のように使用しました。以下のコードを、問題が発生する最小限に減らします。もちろん、私の実際のプログラムでは、メモリはアロケータから別の方法で割り当てられます。

行 reading でデストラクタを呼び出していることがわかります~Function()。コンパイラは受け入れますが、それを呼び出すことはありません: 私は、指定した LLVM コードを実際に削除するかどうかを確認して検証しました (デストラクタにコードを入れてから、 が指す LLVM コードを削除しますcodeptr。Function有効）。

何が原因なのかは後でわかりました。説明をお願いできますか？

デストラクタを呼び出すこれら 3 つのアプローチに重大な/深刻な違いがあるかどうか知りたいだけです。次のコードを検討してください。で述べた 2 つのケースも考慮してくださいmain()。

返信する際は、ケース 1 またはケース 2、またはその両方のケースについて具体的にお答えください。

また、このように書こうとしたTestUsingPlacementNew()のですが、実行時例外(MSVC++2008)を投げています。理由がわかりません：

おそらく、メモリのパディングやアライメントが原因でしょうか?

関連トピック :オブジェクトの配置を破棄した後にデストラクタが呼び出されない - 新規作成

私はプログラミングの練習として C/C++ のガベージ コレクターを書いていますnew。ただし、ガベージ コレクターはunordered_map(割り当てられたブロックへのポインターを格納するために) も使用し、マップがオーバーライドされた new を使用しようとすると、事態は深刻に混乱します (無限にループしようとします)。それを作成するために、オーバーライドされた new の呼び出しを避けるために、placement new を使用したいと考えました。

(mem_t は私が定義した構造体ですが、関連があるとは思いません。) 実行すると、このコードは unordered_map コンストラクター内でセグメンテーション違反を起こします。プレースメント new を使用すれば問題は解決すると思いましたが、どうやらそうではないようです。unordered_map が内部で new を呼び出していることは確かです。アロケータを与えると (どうすればいいですか?)、この問題は解決しますか? そうでない場合、この問題は修正可能ですか?

次の合法的なC++は、明確に定義された動作をしていますか？

または、これはポインタのキャスト/配置の考慮事項のために問題がありますか？

「placement new」を使用する場合は、コンストラクタとデストラクタを明示的に呼び出すことをお勧めします。

この場合、クラスの初期化セクションで初期化されたオブジェクトも適切に構築されますか?

デストラクタを明示的に呼び出しても同じですか？メンバー オブジェクトは適切に破棄されますか?