問題タブ [unique-ptr]

関数ヒープの破損から返された void ポインターに似た問題に直面しています

類似点は、unique_ptr が使用されているスコープを離れるときに「ヒープの破損」メッセージが表示されることです。

ここにコード：

なぜこれが起こるのか分かりますか？

VS2010

unique_ptr私は内部を持つ構造を持っています。次にvector、この構造を持っています。ベクトルのサイズを変更 (または予約を使用) しようとすると、コンパイル エラーが発生します。以下は、まだ問題が発生している簡略化された例です。

unique_ptr私が受け取るエラーは、 (代入演算子) のプライベート メンバーへのアクセスに関する苦情です。コンパイラは、 and を動的に構築しようとしていTest &Test::operator =(const Test &)ますTest::Test(const Test &)。サイズ変更操作でこれらの関数のいずれかを呼び出す必要がある理由がわかりません (必要に応じて、デフォルトのコンストラクターを呼び出さないのはなぜですか?)。. _ unique_ptr_const

この投稿のフォローアップとしてmake_unique、次のコードのように、関数の一時バッファ配列を割り当てることで、その実装がどのように機能するのか疑問に思います。

これをへの呼び出しに置き換えることはできますか？make_uniqueその場合、[]-versionのdeleteが使用されますか？

gcc4.4をgCC4.7に更新しています。これは、4.7を使用するために行います。

私の問題は、を使用するときですunique_ptr。私はこのコードを書きました

ytでも、のようなメンバーを使いたいのですが、uique_ptr::get()取得できる関数は、だけなoperator*ので、何が問題なのでしょうか？

編集：

これが私の問題です： http： //image-load.biz/？di = 6FBY

プレーンなcにunique_ptrを適応させることは可能ですか?

malloc/free を呼び出すときに自家製の「コンストラクタ/デストラクタ」への呼び出しをシミュレートする方法がある場合は、おそらく?

それは実行可能ですか？それともただのばかげた考えですか？

最近、既存のC++アプリケーションコードの多くをC++ 11に移植し始めましたが、新しいスマートポインターstd::unique_ptrとstd::shared_ptrに変換しているので、カスタム削除機能について具体的な質問があります。ラムダロガーを追加して、削除が呼び出されている場所を確認したいのですが、配列の特殊化バージョンをコンパイルできません。アドバイスをいただければ幸いです。

VC++10またはGCC4.5.2 +の配列特殊化unique_ptrのカスタム削除機能の例を無駄に探していました。削除機能がラムダで呼び出されたときにログメッセージを出力したいと思います。主に、スコープ外になると思われるすべてのポインターがそうしていることを確認するためです。これは、スペシャライゼーションのアレイバージョンで可能ですか？非配列バージョンで動作させることができます。また、2番目の引数として外部構造体 "MyArrayDeleter"を渡すと、配列特殊化で動作させることができます。もう1つ、ラムダ署名にそれを理解させることができると思ったので、醜いstd::functionを削除することは可能でしょうか。

私は次のようにコーディングしましたが、C++ は初めてで、ぎこちなく感じます。「spriteBatch」(unique_Ptr) クラス スコープを指定しようとしています。ヘッダーファイルは次のとおりです。

次に、cpp ファイルのコンストラクターで、次のようにします。

「sb」を作成して「spriteBatch」に移動しなければならなかった方法は、不器用に思えます。「spriteBatch」に直接代入しようとして失敗しました (適切な構文がわからないだけかもしれません)。「sb」と std::move を使用する必要を回避する方法はありますか?

ありがとうございました。

最近、既存のクラスの多くをスマートポインターの使用に移行し始めました。スマートポインターを使用することでメリットが得られると思われるコードを移植する方法について、いくつか質問があります（もちろん間違っているかもしれません）。ヘッダーファイルを介して、以下に示すUtlMemBufferバッファーマネージャークラスがあります 。

基本的に、このクラスは、void */lengthのペアで構成されるバッファーのベクトルを所有します。バッファ管理は、ヘルパーメソッド（UtlMemBuffer :: append-その実装も以下に示されています）を介して実装されます。

このクラスで新しいC++11スマートポインターを使用して、所有権を適切に定義し、再割り当てを最小限に抑えたいと思います。このクラスを使用するために、クライアントコードは通常、独自のrawポインターバッファー/長さをコンストラクターに渡すか、appendを呼び出すことができます。最終的に、UtlMemBufferのデストラクタが呼び出されると、UtlMemBufferはそれ自体のコピーを解放し、呼び出し元がそのコピーを担当している間、メモリリークが発生しないようにします。生のポインターを渡す代わりに、std :: shared_ptrを使用すると、このタイプの二重バッファー所有権が不要になると思います（つまり、呼び出し元はstd :: shared_ptrを更新し、それをUtlMembufferに渡す責任があります。

私が見ている最大の課題は、生のポインタを介してフラット化されたメモリを返す必要があるreadメソッド（インターフェイスはファイルの動作方法に似ています）をサポートすることです。おそらく、より良い設計アプローチは、shared_ptrsの内部コレクションをフラット化して作成したstd::unique_ptrを返すことです。最善のアプローチが何であるかはよくわかりませんが、そのアプローチを採用するためにクラスを使用する現在のコードをかなり変更する必要があります。

呼び出し元がすべて、exのstd::shared_ptrポインタを渡す必要があります。この変換を行うための最良のアプローチは何でしょうか。

私はこのスマートポインタビジネスにかなり慣れていないので、アドバイスをいただければ幸いです。ありがとう

これは、バッファブロックのベクトルへのアクセスを管理するヘルパーメソッドです。ご覧のとおり、rawポインターを再割り当てし、mBufferBlocksメンバーに格納します。

私は持っています

VS10のマークされた行でコンパイルエラーが発生します。この場合、不完全な型を使用することを許可するべきではありません（例として、ここではintの場合、テンプレート（コンストラクター）をインスタンス化します）？回避策はありますか？

編集

私は流暢なインターフェースパターンで遊んでいます。

まず、私はそのようなものを書きました：

次に、std :: unique_ptrを使用しようとしましたが、チェーンに沿ってポインター（this）を「シフト」する方法がわからないことに気付きました。私は次のようなことを試しました：

もちろんそれは機能しません。

これどうやってするの？このようなことをするのに何か問題はありますか？

「ポインタを使わないでください」のようなコメントに返信するために：私はポインタを使ってこれを行っているので、（まだ）実用的な理由はありませんが、この方法でできるかどうか疑問に思っています。