問題タブ [unique-ptr]

派生クラスFoo<T> へのスマートポインタのベクトルを持つクラスがあります。メンバー関数Shapeを実装しようとしています。at(index)これが私が直感的に行うことです：

関数を定義するとat(index)、コンパイラエラーメッセージが表示されます。移動コンストラクターが定義されており、Shape基本クラスが抽象であることに注意してください。以下に、説明のためにいくつかのコードを示します。

さらに、最近Webで、を使用して代入演算子をオーバーロードする方法の例を見つけましたstd::move。私は通常、コピースワップのイディオムに従います。上記の演算子をオーバーロードするためのこれらの2つの方法のどちらが、私の場合に意味がありますか？以下に、関数の定義も示します。

コード：

Visual C++ 10.0 および MinGW g++ 4.4.1 でのエラーの例:

配列バージョンは、非配列バージョンと同じ暗黙の const 追加を受け入れる必要があるように思えます。

違いは、配列バージョンが派生クラスへのポインターを受け入れてはならないことであり、それが明らかに上で作動する機構です。

コードは有効ですか？

コードが正式に無効である場合、標準の文言はその意図を反映していますか (つまり、DR は適切ですか)?

最初の質問が「いいえ」で、2 番目の回答が「はい」の場合、意図に欠陥がありますか (つまり、DR は適切ですか)?

別のデータ オブジェクトから取り込まれた新しい Foobar オブジェクトを返す静的ファクトリ メソッドを作成しました。私は最近、所有権のセマンティクスに夢中になっており、このファクトリ メソッドにunique_ptr.

私の意図は、ポインターを所有していることをクライアント コードに伝えることです。スマート ポインターがなければ、単純に を返しFoobar*ます。ただし、潜在的なバグを回避するためにこのメモリを強制的に削除したいのでunique_ptr、適切な解決策のように思えました. クライアントがポインターの有効期間を延長したい場合は.release()、unique_ptr.

私の質問は2つの部分に分かれています：

1. このアプローチは正しい所有権のセマンティクスを伝えていますか?
2. unique_ptrこれは、生のポインターの代わりに返す「悪い習慣」ですか?

のコンテナはunique_ptrほとんど意味がないようです。初期化リストでは使用できず、コンテナを反復処理できませんでした（以下の回避策）。私は何かを誤解していますか？unique_ptrまたは、STLコンテナを使用するのはいつ意味がありますか？

• 初期化子リストを使用してコピー不可能なコンテナを初期化する方法は？

• 移動専用タイプのベクトルをリストして初期化できますか？

• 普段使っているNoCopyタイプのコンテナが必要なときboost::ptr_vectorやstd::vector<shared_ptr>

作成中のクラスのメンバーとして、unique_ptr のベクトルが必要です。

しかし、その後、 VS2010コンパイラから不可解なエラー メッセージが表示され始めます。

マイクロソフトの実装に飛び込むその下のいくつかのエラー行とともにstd::_Copy_impl<>...

メンバー宣言を次のように変更しました

そしてコンパイルします。でも、どうして本来の思い通りにできないのだろうと思わずにはいられない。笑顔のために、私はこれを試しましたが、うまくいきます：

しかし、今では利便性を失っていますunique_ptr。ケーキも食べたい！

これは、pimpl に unique_ptr を使用しようとしたときに表示されるものを簡略化したものです。クラスにポインターを所有させたいので、unique_ptrを選択しました-pimplポインターとクラスの寿命を同じにしたいのです。

とにかく、ここにヘッダーがあります：

ソースは次のとおりです。

これらをライブラリにコンパイルできました。しかし、テストプログラムでそれを使用しようとすると、

これはよく知られている安全機能です。フォローしてみました。

私の問題は、Help::Impl 宣言をヘッダーに入れると、pimpl の利点がなくなるように見えることです。クラスのレイアウトはユーザーに表示されます。定義は非表示になっていますが、Help クラスとプライベート メンバーを使用してそれを行うこともできました。また、Impl の宣言を含めることで、別個に保持したかった新しいヘッダーが取り込まれます。

私は何が欠けていますか？人々は Impl 宣言に何をどこに入れますか? Help dtor のやり方が間違っていますか? ああ！

不完全な型で動作する非共有ポインターである標準ポインター クラス (またはブースト) はありますか? 私は C++11 標準と boost ライブラリを調べましたが、非常に便利なタイプのように見えますが、見つけることができません。

たとえば、スマート ポインターを使用して不透明な型を作成できるようにしたいと考えています。

A様々な用途に使用できる不透明タイプです。上記のインターフェースのユーザーは A の不完全な定義しか持っていませんが、ポインターを削除/リセットできるはずです。上記は a で実行できることはわかっていますがshared_ptr、この特定のコードでは望ましくないオーバーヘッドがあります。unique_ptr正しい所有権のセマンティクスがありますが、不完全な型では機能しません。理論的には、ラッパーはデリータへのポインタを持つオーバーヘッドのみを必要とするはずです。

C++11 またはブースト ライブラリにそのような型はありますか?

注: このタイプを簡単に作成できることは理解していますが、可能であれば標準タイプを希望します。基本的なスマート ポインター型である必要があるようです。

更新:unique_ptr良いオプションではないようです。まず、構文のオーバーヘッドが相殺されます。第二に、カスタム デリーターで安全に使用できるとは確信していません。どのように機能するかを確認します。

C++ 11 で導入された新しいポインター テンプレートを使用して配列のスコープを管理するクリーンな方法を探しています。ここでの典型的なシナリオは、win32 API 関数を呼び出す場合です。

私がここに投稿しているのは、より複雑な問題については多くの議論がありますが、この比較的単純なシナリオは議論されていないようで、私が今始めていることよりも良い選択肢があるかどうか疑問に思っているからです.

このコードを考えてみましょう：

arr1とarr2は、同じメモリ領域を指します。したがって、それらは同じ値を共有します。arr2 = get（）を呼び出すと、その理由がわかりません。

このオブジェクトを再度作成するべきではありませんか？arr1でまだ到達可能であるため、削除されません。異なるメモリ領域の2つの配列を取得するにはどうすればよいですか？

c ++ 11があるので、c++11のboost::ptr_containersの代わりがあるかどうか自問していました。たとえば、を使用できることはわかっていますstd::vector<std::unique_ptr<T> >が、これが完全な代替品であるかどうかはわかりません。これらのケースを処理するための推奨される方法は何ですか？