問題タブ [unique-ptr]

Grid型でテンプレート化された単純な2Dコンテナである古いクラスを掘り起こしました。1つを作成するには、次のようにします。

私はそれを「Qt-ish」にしようとしました...たとえば、それはの観点からサイズ操作をQSize行い、あなたはそれにインデックスを付けmyGrid[QPoint (x, y)]ます。ブールマスクを取り、マスクビットが設定された要素に対して操作を実行できます。あなたの要素があればそれがあなたのためにQColor生成することができるという専門分野もありQImageます。

しかし、私が採用した主要なQtイディオムの1つは、内部で暗黙的に共有することでした。これは、私が持っていたThinker-QtベースのプログラムのQColorベースのグリッドで非常に役立つことがわかりました。

しかし：-/私はたまたま次のようなものを書いた場合もありました：

auto_ptr私がC++11に移行したときunique_ptr、コンパイラは当然のことながら文句を言いました。暗黙の共有には、必要に応じて同一のコピーを作成する機能が必要です...そして、auto_ptrコピーと所有権の譲渡を混同することで、このバグを一掃しました。コピー不可能なタイプと暗黙の共有は単純に混ざり合うことはなく、unique_ptr親切にも教えてくれます。

（注：のユースケースは、値ではなく参照によってグリッドを渡すため、実際には問題に気付かなかったことがありましたauto_ptr。それでも、これは悪いコードでした...そしてCのプロアクティブな性質++ 11は、発生する前に潜在的な問題を指摘しています。）

では、暗黙の共有のオンとオフを切り替えることができる汎用コンテナをどのように設計すればよいでしょうか。を使用していたときに、グリッド機能の多くが本当に必要でした。auto_ptrコピーできないタイプのコピーが無効になっていると、エラーが発生します。ただし、タイプがコピー可能である場合、デフォルトで暗黙的な共有が機能するのは便利です。

いくつかのアイデア：

• 私はあなたの好みに応じて別々のタイプ（NonCopyableGrid、CopyableGrid）...または（UniqueGrid、 ）を作ることができます...Grid
• Gridコンストラクターにフラグを渡すことができます
• 静的ファクトリメソッド（Grid::newNonCopyable、Grid::newCopyable）を使用することもできますが、内部で関連するコンストラクターを呼び出すことになります...おそらくもっと説明的です
• 可能であれば、含まれているタイプのコピー可能性を「検出」してから、実装でQSharedDataPointerを活用するかどうかに応じて、

これらの方法の1つを他の方法よりも選択する正当な理由はありますか、または人々はこの種の状況に完全に優れた方法を採用しましたか？

現在、生のポインターを使用する広範なコード ベースがあり、unique_ptr に移行したいと考えています。ただし、多くの関数はパラメーターとして生のポインターを想定しており、これらの場合に unique_ptr を使用することはできません。get() メソッドを使用して生のポインターを渡すことができることはわかっていますが、これにより、触れる必要があるコードの行数が増え、少し見苦しくなります。次のような独自の unique_ptr を作成しました。

次に、生のポインターを期待する関数 parm に my_unique_ptr を提供するたびに、自動的にそれを生のポインターに変換します。

質問: これを行うことについて本質的に危険なことはありますか? これは unique_ptr 実装の一部であると思っていたので、その省略は意図的なものだと思います-誰かが理由を知っていますか?

この投稿の手順に従った後、Eclipse (Indigo) を認識させることができましたunique_ptr(およびその他の C++11 の新機能)。問題は、operator->forunique_ptrが Eclipse でサポートされていないように見えることです。ここに例があります：

ケース1は期待どおりに機能します。エラーはなく、オートコンプリートが機能します。ただし、ケース2の場合、Eclipse はステートメントにエラー (「メソッド 'bar' を解決できませんでした」) をマークし、さらに からのオートコンプリートはfoo->機能しません。

最も興味深いことに、私は に問題はありませんstd::shared_ptr。に対してのみ発生しstd::unique_ptrます。

誰も同じ問題を経験しましたか? 誰かがそれを修正する方法を知っていますか?

編集:目的を明確にするために、上記のコード スニペットのコンパイル プロセスは正常に行われます。したがって、問題はコンパイラ自体ではなく、Eclipse にあります。

OK、最初に関連する可能性のあるいくつかのこと:

Clang 3.1 コンパイラを C++11 モードで使用し、標準ライブラリを libc++ に設定しています。

私は C++11 に慣れようとしていますが、そうしているうちに奇妙な動作に出くわしました。それはClangまたはlibc ++の癖かもしれませんが、私はC ++標準語を話すことができず、C ++ 11をサポートする他のコンパイラにアクセスできないため、実際に確認することはできません。インターネットとスタックオーバーフローを検索しました関連するものを見つけることなく、私の能力を最大限に発揮します...だからここに行きます：

shared_ptr / unique_ptr を使用して単純なリソースの RAII を実装する場合、削除時の null ポインターに関してそれらの動作が異なるようです。通常、ヌル ポインターを削除する必要はないことは認識していますが、少なくとも 2 つの STL スマート ポインター間で動作が一致することを期待していました。

特定のケースでは、次のコードを検討してください。

これから、次のいずれかの出力が期待されます。

a) ポインターがヌルであっても、両方のデリータが呼び出された場合:

b) ポインターが null であるため、どちらのデリータも呼び出されない場合:

しかし、私はこれらのケースのどちらも観察しません。代わりに、私は次のことを観察します。

これは、一方のデリータが呼び出され、もう一方が呼び出されていないことを意味します。さらに調べてみると、shared_ptr のデリータは null 値を保持しているかどうかに関係なく呼び出されますが、unique_ptr のデリータは null 値を保持していない場合にのみ呼び出されることがわかりました。

私の質問: これは実際に標準で指定されている正しい動作ですか? もしそうなら、なぜこのように 2 つの STL タイプ間で指定された動作が異なるのでしょうか? そうでない場合、これは libc++ に報告すべきバグですか?

これは、unique_ptrを使用するコードです。

実行の出力は次のとおりです。

bar()私が理解したことから、 ingのためにup破壊されることになっていたので、私は呼び出しが失敗することを期待していました。私は正しく理解していないようです。誰かが私に何が起こっているのかを教えてもらえますか？（g ++ 4.7.0）vmove

特定の複雑なアプリケーションにlibsvmを使用しようとしていますが、libsvm はほとんどが C ライブラリであるため、特定のデータをロードした後、カスタム API 関数を使用してメモリを解放する必要があります。これが私が意味することです：

以下は、私が使用した libsvm API 関数の定義です。

これで問題なく動作しますが、モデル データの処理中に例外が発生すると、メモリ リークが発生します。これを防ぐために、上記のコードをクラスにラップsvm_load_modelし、コンストラクターとsvm_free_and_destroy_modelデストラクターで呼び出します。

さて、私たちはスマート ポインターの時代にいるので、もう少しクリエイティブになり、どうにかしてモデル変数を として宣言しstd::unique_ptr、ポインターをsvm_free_and_destroy_modelカスタム デロケーターとして設定することを考えていましたが、残念ながら、そうではありません。そのようなことが可能かどうかを判断することができます。現時点では、コンパイルすることさえできず、暗闇で撮影しているだけです。これが私がそれがうまくいくと思う方法です：

unique_ptr と move-semantics の両方を利用する pimpl の例はまだ見たことがありません。

CHelper クラスを STL 派生コンテナーに追加し、pimpl を使用して CHelper の機能を隠したいと考えています。

これは正しく見えますか？

Derived.h

`

Helper.h

Helper.cpp

C++11 を初めて使用しようとしていunique_ptrます。私のプロジェクト内のポリモーフィックな生のポインターを置き換えています。これは、1 つのクラスによって所有されていますが、非常に頻繁に渡されます。

以前は次のような機能がありました。

しかし、すぐに次のように切り替えることができないことに気付きました。

呼び出し元は関数へのポインターの所有権を処理する必要があるため、私はしたくありません。それで、私の問題に対する最良の解決策は何ですか？

次のように、ポインターを参照として渡すことを考えました。

_ptrしかし、私はそうすることに非常に不快に感じます.1つ目は、すでに入力されているものを参照として渡すことは本能的ではないように思われるためです。第二に、関数のシグネチャがさらに大きくなるためです。第 3 に、生成されたコードでは、変数に到達するために 2 つの連続したポインター間接参照が必要になるためです。

テンプレート化されたタイプのプレーンな古いポインターに対して、これらに代入演算子のオーバーロードがない理由はわかりません。スマートポインターを可能な限り単純な古いポインターに近づけるという目標がある場合、なぜこのような代入演算子のオーバーロードを作成しなかったのでしょうか。

このようにして、通常のポインタと同じようにそれらを使用できます。

それはまったく問題ではなく、なぜ彼らが数人のオペレーターに過負荷をかけるだけの問題に直面したのか疑問に思っています。

また、これを行うためにグローバル代入演算子をオーバーロードする方法があるかどうか、または私がすべきではない理由があるかどうか疑問に思っています。

編集：コードフォーマットに関するここでの彼の答えについてのNawazへの応答を追加します。私はあなたが言っていることが正しいかどうかを確認するためにこのテストプログラムを書いたばかりです：

peh<int>これは、からへの使用可能な変換がないと言ってエラーになりint *ます。では、なぜそれが受け入れstd::shared_ptr<int>られるのint *でしょうか？

このクラスを書いてみました

UniqueElement は、別の場所で定義された POD クラスです。コンストラクタ本体を次のように定義します。

そしてそれは例外なく遵守します。ContainerUniqueプログラムを実行すると、コンストラクターが呼び出された後uに null ポインターが含まれていることがわかりました。

これは意図した動作ですか？そして、実際に呼び出している unique_ptr メソッドは何ですか?