問題タブ [smart-pointers]

まず、さまざまな種類のスマート ポインターがあるため、この質問ではそのうちの 2 つに焦点を当てたいと思います。参照カウントの侵入型スマート ポインターと非侵入型スマート ポインターです。質問は、ポインターの種類ごとに個別に尋ねられます。

私は自分の質問をどのように定式化するのかよくわかりません. どのタイプのスマート ポインターを何のために使用するべきか。

これが私が求めていることであり、それが十分に明確であることを願っています.「スマートに管理された」オブジェクトを扱うとき、どのコンテキストでどのポインターセマンティクスを使用する必要がありますか? つまり、スマート ポインターのセマンティクス、生のポインターのセマンティクス、その他 (スマート ポインターへの参照など) ですか?

グローバル ポインターなどのオブジェクト (参照カウント メモリ エンティティであるオブジェクト) へのポインターを "格納" する場合、またはクラス メンバーとして、それはスマート ポインターである必要があるため、所有権を主張することは明らかですが、他の状況はどうですか？

ポインターを関数の引数として渡す場合、それはスマート ポインター、生のポインター、スマート ポインターへの参照、またはその他のものである必要がありますか? 返されたポインタはどうですか? ローカルポインター？すぐ...

もちろん、どこでもスマート ポインターを使用できますが、これは最も安全なオプションですが、これは本当に不必要であり、オーバーヘッドが増えると感じています。

fooコンストラクトをコピーしたい std::auto_ptr メンバーを含むクラスがありますが、これは許可されていないようです。課題についても同様のことがあります。次の例を参照してください。

_casと宣言することもできますmutableが、これが正しいかどうかはわかりません。誰かがより良い解決策を持っていますか?

編集

OK、期待していたような回答が得られないので、問題についてもう少し具体的に説明します。

• タイプのオブジェクトがfooスタック上に作成され、値によってコンテナー クラス (stl ではない) に渡された後、スコープ外になります。コンテナー コードを制御することはできません。(実際には、バグのあるアクティブ キューの実装です。)
• このbarクラスは、かなり重量のあるパーサーです。パフォーマンスが非常に低いnewためdelete、コピー構築可能であったとしても、コストがかかりすぎます。
• barオブジェクトが作成されると、一度に 1 か所だけ所有する必要があることを保証できます。この場合、スレッド間で渡され、トランザクションが完了すると削除されます。これが、私が a を使用することを望んでいた理由ですstd::autp_ptr。
• ブースト スマート ポインターを検討したいと思っていますが、代替手段があれば、この一意性を保証したいと考えていました。

スマートポインターのリストがあります。これらのスマート ポインターの一部を通常のポインターとして機能させたいと考えています。つまり、それらは単にインスタンスへの参照であり、その解放には関与しません。たとえば、スタックに割り当てられたインスタンスを指す場合があります。リスト内の他のスマート ポインターは、通常の boost::shared_ptr として機能する必要があります。

クラスは次のようになります。

これを行うブースト クラスがある場合は、自分でクラスを作成する代わりにそれを使用することをお勧めします。何もないように見えますが、間違っていますか?

boost::shared_ptr などの一部のスマート ポインター テンプレートは、任意のオブジェクトを保持するために void でインスタンス化できます。

http://www.boost.org/doc/libs/1_39_0/libs/smart_ptr/sp_techniques.html#pvoid

以下は最小限の scoped_ptr 実装です。void を使用してインスタンス化すると、逆参照演算子で不正な「void への参照」が形成されていることについて、コンパイラからエラーが発生します。「置換の失敗はエラーではない」(SFINAE) ルールは、この状況をカバーしていないようです。

では、scoped_ptr を実装するにはどうすればよいでしょうか? 特に、テンプレートの特殊化を作成する代わりの方法はありますか? これにより、現実的なスマート ポインターの実装で大規模なコードの重複が発生します。

私はスマート ポインター countptr を作成している最中で、スピード バンプにぶつかりました。countptr の基本的な機能は、他のスマート ポインターと同じように機能し、1 つのオブジェクトを指しているポインターの数をカウントすることです。これまでのところ、コードは次のとおりです。

[解決済み]

私が何かをしようとすると

次に、「'*(&one)->counted_ptr::operator->with T = double' のメンバー 'pointer' を要求します。これは非クラス型 double です」というコンパイラ エラーが発生します。

これを行う関数を作成することを検討しましたが、T の配列を割り当てる関数を作成できましたが、実際のオブジェクトを割り当てる関数を作成する方法が思いつきません。どんな助けでも大歓迎です、ありがとう。

スマートポインタのインスタンスをコンテナに保存するのに問題があります。ポインタのコードは次のとおりです。

int main（）では、vector<counted_ptr<double> >行はコンパイルされます。最初に試したときvector<counted_ptr<double> >はコンパイルされませんでした（おそらくパラメーターが不足していたためです）。ただし、次のようなpush_backを使用しようとすると

vector.tccを開くコンパイラエラーが発生し、特定のエラーが発生します。

push_backはcounted_ptrを見つけることができないと思いますが、本当にわかりません。どんな助けでもありがたいです、ありがとう。

編集：ただし、これは機能します。test [0] =1; push_backのセマンティクスがそれを制限していると思います。

「this」ポインターをスマートポインターと組み合わせて使用​​しないようにするにはどうすればよいですか？これを回避するためのデザインパターン/一般的な提案はありますか？

次のいずれかなので、2つを組み合わせるのはノーノーだと思います。

1. そもそもスマートポインターを使用するという点を打ち負かす、スマートポインター管理オブジェクトへのネイティブポインターを渡しているのです。
2. 「this」ポインターを使用時にスマートポインターでラップすると、たとえば「return CSmartPtr（this）;」のように、同じオブジェクトを管理する複数のスマートポインターが効果的に設定されるため、最初のポインターの参照カウントはゼロになります。他の下からオブジェクトを破壊する、または
3. これらの場合に返すCSmartPtr（this）の値を保持するメンバー変数がある場合、最終的には循環参照になり、参照カウントは常に1になります。

少しコンテキストを与えるために、私は最近、STLコンテナーをオブジェクトと組み合わせる場合の悪影響（浅いコピーの繰り返し、基本クラスのコンテナーを使用する場合のスライスなど）について学びました。そのため、コードでのこれらの使用法の一部を次のように置き換えます。オブジェクトへのスマートポインタ。いくつかのオブジェクトは、「this」ポインタを使用して自分自身への参照を渡します。これは私が立ち往生している場所です。

スマートポインタ+「これ」は有害だと考えられていますか？やや似たような問題について尋ねましたが、私はBoostを使用していないので、答えは役に立ちません。

編集：私がやっていたことの（非常に工夫された）例は次のようになります

スマート ポインターはダウン キャストを処理しますか?そうでない場合、この制限を回避する安全な方法は何ですか?

私がやろうとしていることの例は、スマート ポインターを含む 2 つの STL ベクトル (たとえば) を持つことです。1 つ目は基本クラスへのスマート ポインターを含み、2 つ目は派生クラスへのスマート ポインターを含みます。スマート ポインターはカウントされて参照されます。たとえば、Boost の shared_ptrs と同様の動作ですが、手動でロールされます。例を提供するために作成したサンプルコードをいくつか含めました。

同じオブジェクトを管理する 2 つのスマート ポインターで終わると思うので、これは私には安全ではないようです。トラックのどこかの時点で、これはおそらくオブジェクトへの参照を保持している間に、一方がオブジェクトを解放するという結果になるでしょう。

私が望んでいるがうまくいくとは思わないのは、同じオブジェクトを維持しながらまっすぐにダウンキャストすることです。

CBaseSmartPtr を使用し、使用時にのみダウンキャストするように 2 番目のコンテナーを変更する必要がありますか? 他の解決策はありますか？

私が遭遇した単なる概念的な質問。smart_ptr私の現在のプロジェクトでは、ブーストとptr_containerライブラリを使いすぎているように感じます。私はboost::ptr_vectors 多くの異なるオブジェクトを作成し、transfer（）メソッドを呼び出して、特定のポインターboost::ptr_vectorを別のポインターに移動していました。

ヒープに割り当てられたオブジェクトの所有権を明確に示すことが重要であると私は理解しています。

私の質問は、これらのブーストライブラリを使用して、オブジェクトに属するヒープ割り当てメンバーを作成しget()、処理を行うときにこれらのメンバーへの通常のポインタを使用することが望ましいかどうかです。

たとえば...ゲームには、それに属するタイルのコレクションが含まれている場合があります。これらのタイルをで作成することは理にかなっているかもしれませんboost::ptr_vector。ゲームが終了すると、これらのタイルは自動的に解放されます。

ただし、これらのタイルを一時的にBagオブジェクトに入れたい場合は、バッグ内に別のタイルを作成しboost::ptr_vectorてを介してゲームのタイルをバッグに転送するか、Tiles*がゲーム内のタイルを参照transfer()する場所を作成して渡す必要があります。std::vector<Tile*>バッグに？

ありがとう。

**編集私の例では、ゲームにはメンバーとしてBagオ​​ブジェクトが含まれることを指摘しておく必要があります。バッグは、ゲームが所有するタイルでのみ満たされます。したがって、バッグはゲームなしでは存在しません。

C++ の参照は、次の C コードを単純化できる便利な構造です。

に

共有ポインターは、メモリ管理を簡素化する C++ のもう 1 つの便利な機能です。ただし、参照によって引数を受け入れるshared_ptrような関数に aを渡す方法がわかりませんか?f(object& o)

オブジェクトが関数への参照によって渡されると、共有ポインタはインクリメントされますか?