問題タブ [scoped-ptr]

scoped_ptrはコピーできず、スコープ外で削除されています。だからそれは一種の制限されていshared_ptrます。したがって、本当にコピー操作を制限する必要がある場合以外に、shared_ptr使用する方がよいようです。オブジェクトのコピーを作成する必要があるかどうかわからない場合があるためです。したがって、問題は次のとおりです。上記の場合に加えて、のshared_ptr代わりに使用する方が良い（または推奨される）と考えられますかscoped_ptr。scoped_ptrからはるかに高速に動作しますかshared_ptr、それとも何か利点がありますか？

ありがとう！

または、それを行う必要がある場合は、shared_ptr を使用する必要がありますか?

私は構造を持っています

を使用して作成できます

そしてを使用して削除

構造に割り当てられたメモリを自動的に解放したい

この目的のために、私はテンプレートを書きました

そしてそれをそのように使う

stlまたはboostを使用して、より標準的な方法にするにはどうすればよいですか？

メンバー変数としてポインターを含むクラスがある場合、単純なポインターを使用したくない場合、どのタイプのスマート ポインターを使用する必要がありますか? 共有する必要はありません (したがって、shared_ptr は必要ありません)。scoped_ptr は、初期化リストの外でオブジェクトを構築する必要があることが多いため、機能しません。

それとも、何かがまだ失敗する可能性がある場合 (例外がスローされるなど)、作成中に scoped_ptr を使用し、その後それらをプレーン ポインターに割り当てるのが一般的な方法ですか?

タイプのクラスメンバーをboost::scoped_ptrクラスのコンストラクター内で初期化できますか？どのように？
（初期化リストにはありません）

そこで、クラス作成のために boost.extension 関数の周りにラッパーを作成しようとしました。だから私は関数を作成しました：

呼び出す：

しかし、最後はそれほど重要ではありません。重要なこと - 関数 return=( を取得できません

私はそのように試みます：

私も試しました：

しかし、コンパイラは私に背を向けてC2248、それはいくつかのプライベートメンバーを呼び出すことができませんboost::scoped_ptr<T>

では、どうすれば返品できるようになります... 返品可能 // どのように受け取るのですか?

一般的に、私は Google のスタイル ガイドに従います。これは、私が物事を見る方法とうまく一致していると感じています。また、ほぼ例外なく、boost::scoped_ptr を使用して、特定のオブジェクトの所有権を 1 人のマネージャーだけが持つようにしています。次に、裸のポインターを渡します。私のプロジェクトは、オブジェクトを使用するオブジェクトが破棄された後、そのオブジェクトのマネージャーが常に破棄されるように構造化されているという考えです。

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Smart_Pointers

これはすべて素晴らしいことですが、所有者を使用していたオブジェクトが削除される前に、所有者がたまたま削除されてしまうという厄介な小さなメモリストンプバグに噛まれました.

さて、みんなが私がこのパターンのばかだと飛び跳ねる前に、単に shared_ptr を使用しないのはなぜですか? など、未定義の所有者セマンティクスを持ちたくないという点を考慮してください。shared_ptr はこの特定のケースをキャッチできますが、システムのユーザーに間違ったメッセージを送信します。「誰がこれを所有しているのかわかりません。あなたかもしれません!」と書かれています。

私を助けたのは、スコープ付きポインターへの弱いポインターだったでしょう。実際には、スコープ付きポインターが破棄されると null になる弱参照のリストを持つスコープ付きポインター。これにより、単一所有権のセマンティクスが可能になりますが、使用中のオブジェクトに、私が遭遇した問題をキャッチする機会が与えられます。

したがって、scoped_ptr の追加の「weak_refs」ポインターと、weak_ptr の「next_weak_ptr」の追加ポインターを犠牲にして、きちんとした小さな単一所有者、複数ユーザー構造を作成します。

それはおそらく単なるデバッグ機能である可能性もあるため、「リリース」では、システム全体が通常のサイズの scoped_ptr と弱参照用の標準の単一ポインターに戻ります。

だから.....これのすべての後の私の質問は次のとおりです。

1. stl/boost に既にそのようなポインター/パターンがありませんか、それとも自分でロールする必要がありますか?
2. 私の単一所有権の目標をまだ満たしている、より良い方法はありますか?

乾杯、シェーン

boost::scoped_ptr<T>との間の唯一の違いは、移動セマンティクスstd::unique_ptr<T>を持っているのに対し、単なるget / resetスマートポインターですか？std::unique_ptr<T>boost::scoped_ptr<T>

私は通常、pimplにboost :: scoped_ptrを使用します（コピーコンストラクターを処理するのを忘れても驚きがないため、1つの理由があります）

ただし、テンプレートでは、scoped_ptrのデストラクタの要件を満たすために、implが完全に定義されているcppファイルにデストラクタを配置することはできません。とにかく動作しますが、動作することが保証されているのか、それとも偶然なのかはわかりません。「ベストプラクティス」または標準はありますか？scoped_ptrは、コピー不可能なクラスのpimplsに最適なスマートポインターですか？

boost::scoped_ptr を使用して単純なシングルトンを実装しました。

実際のシングルトン クラスを定義します。

次に、ファイル S.cpp で静的変数を定義します。

main.cpp で:

このプログラムを実行すると、例外が発生しました:

/usr/include/boost/smart_ptr/scoped_ptr.hpp:91: T& boost::scoped_ptr::operator*() const [with T = S]: アサーション `px != 0' が失敗しました

コードをトレースすると、コードが静的初期化セグメントを離れると静的 s_instance.t がクリアされ、その後、S::instance を参照するすべてのコードが NULL scoped_ptr を取得することがわかりました。誰も理由を知っていますか？

[更新] すべての静的ファイルを 1 つの cpp ファイル (S1.cpp) に入れようとしました。

GDBでデバッグすると、書いた順番通りに見えます。何か案が？