問題タブ [shared-ptr]

最近、次のメモリ バグが発生しました。ここでは簡単に見つけることができますが、より複雑なコードでは検出が難しくなる可能性があります。

バグは、Barすぐに範囲外になり、破棄されてから で使用されることfoo->test()です。Bar1 つの解決策は、を使用してヒープ上に作成することBar* bar = new Bar()です。ただし、特定のコードブロックに固有のものであっても、最後にBar* barアクセスできるようにポインターをトップレベルに保持する必要があるため、これを行うのは好きではありません。deleteBarif(whatever){}

別の解決策は ですがboost::shared_ptr<Bar>、これだけを書くことはできません:

もすぐに範囲外になりshared_ptr、含まれているオブジェクトが破棄されるためです。

要するに、この問題を取り除くには、どこでも、メンバー変数として、のコンストラクターなどを使用shared_ptrする必要があります。これらの問題を一般的に解消するには、すべての API などで を使用する必要があります。醜い。しかし、それは正しいことですか？これまでのところ、参照カウント オブジェクトを作成するために時々使用してきましたが、API をクリーンな状態に保っています。一度使用すると、どこでも使用しなければならないというこの問題にどのように対処しますか?FooFooshared_ptrshared_ptrshared_ptr

(また、これらの参照カウント ポインターを使用する場合は、本当に必要shared_ptrかどうかweak_ptrなどについて心配し始める必要があります。)

そして、私は何を同等のものとして使用しFoo(const Bar& bar)ますか? Foo(const shared_ptr<const Bar> bar)?

もちろん、別のオプションとして、Barおよび他のオブジェクト内に参照カウントを追加pimplし、独自のカウンターを使用することもできますが、一般的なルールとしては面倒です。

可変オブジェクトへのスマートポインターのコンテナーがあります。2つのfor_eachループを作成する必要があります。1つは読み取り専用データとしてオブジェクトにアクセスするためのもので、もう1つは可変データ用です。std::vector< boost::shared_ptr<Object> >コンパイラは、と同じではないと言っています。std::vector< boost::shared_ptr<const Object> >に注意してくださいconst。

これが私のサンプルコードです：

Record_Base上記のすべての詳細を考えると、 inの純粋な抽象メソッドを実装するにはどうすればよいRecord_Derivedですか？

私はもう試した：

• を返します。これ は変換エラーを返します（変換できませm_fields.begin()ん）
  std::vector<...> to Field_Iterator
• を返す&m_fields[0]。これは、の内部に関するものを想定しているため、危険ですstd::vector。

ところで、std::for_eachフィールドのコンテナとサブレコードのコンテナを反復処理する必要があるため、使用していません。

私は現在、スマートポインターの使用を導入することにより、コードベースのいくつかの弱点を修正しようとしています。コードベースは非常に大きく、1対多のコーヒーを飲んだクモのように相互に関連しています。

人々が以前に試したことがあるのか​​、そして彼らのアプローチは何だったのかと私は思っていました。

私の最初のステップは、次のようにtypedefクラスを作成することでした。

今、私はこれが次のような豊富なコンパイル領域につながることを理解しています

スマートポインタが有効になっていると、完全に失敗します。

コンパイルエラーの量を減らすために、この早い段階で何かできることがあるのだろうか、それともケースバイケースで物事をとっているのではないかと思っていました。

乾杯リッチ

メンバ変数が他のクラスのオブジェクトへの boost::shared_ptrs である C++ クラス (dll プロジェクト内) があります。クラスコンストラクター内でそれらを割り当てる方が良いですか、それとも別の init() 関数を使用する方が良いですか?

boost::shared_ptr 内の T へのポインターのデフォルト値は NULL であると想定しています。したがって、コンストラクター内で何もしないと、Boost::shared_ptr の get() は Init() 関数を呼び出す前に NULL を返します。

また、割り当てステートメントの 1 つで new にメモリ割り当ての問題がある場合、(Init で) 例外をキャッチする必要がありますか、それともこの Init() の呼び出し元にその例外をキャッチするように指示するのがよいでしょうか? boost::shared_ptr a( new T);

単体テスト内でメモリ割り当ての例外をシミュレートする標準的なアプローチはありますか? すべてのオブジェクトが適切に割り当て解除されていることを確認します

私はグーグルを十分に行ったので、

次のようなダミーの宣言がある場合、Doxygenに「正しい」コラボレーション図を作成させることができます。

私のヘッダーファイルで。

私の質問は、すべてのファイルにその行を実際に含めることなく、すべてのプロジェクトとすべてのヘッダーでそれを機能させるにはどうすればよいですか？

私は今、古い C コードをハックしています。より C++/Boost スタイルにしようとしています:

次のようなリソース割り当て関数があります。

私はshared_ptrでsrcをラップしようとしています:

今言い忘れました。これをループとして行う必要があります

私はこのようにすることができますか？

Lua 用の C++/OOP ラッパーを作成しています。私のコードは次のとおりです。

問題は lua_State が不完全な型であり、shared_ptr コンストラクターが完全な型を必要とすることです。そして、安全なポインタ共有が必要です。(面白いことに、ブーストのドキュメントでは、ほとんどの関数は完全な型を必要としないと書かれていますが、コンストラクターは完全な型を必要とするため、それを使用する方法はありません。http://www.boost.org/doc/libs/1_42_0/libs/smart_ptr/smart_ptr.htm )

これを解決できますか？ありがとうございました。

私のクラスでは、コンストラクターはプライベートであり、コンストラクターを使用してその share_ptr を返す静的メソッド「CreateMyClassPtr」を追加しました。

それは正しい実装ですか？

それが使用されることを確認する必要さえあると思いますshared_ptrか？決定するのはユーザーに任せるべきでしょうか？

オブジェクトを共有する必要はありませんが、メモリ リークが発生しないようにしたいと考えています。この場合、shared_ptr を使用するのは正しいですか?

バインド関数で削除されないようにオブジェクトへの参照を保持したいのですが、ヘルパー関数を使用しません。

holdReference関数を適切に宣言する方法はありますか？ラムダ式やsthのように？（この厄介なholdReference関数を使用せずに、fun関数の範囲外で宣言する必要があります）試行回数はほとんどありませんでしたが、コンパイルされていません:)

わかりました、ここにもっと詳細な例があります：