問題タブ [unique-ptr]

私は奇妙なセグメンテーション違反に遭遇しました。原因は実際に私をバグに導きました、しかし私はまだセグメンテーション違反がここで引き起こされる理由を理解していません...コードは次のとおりです：

g ++ 4.6でコンパイルすると-std=c++0x、セグメンテーション違反が発生します。

7行目をu2 = std::move(u1);（それがバグでした）に変更すると、消えます。8行目をstd::shared_ptr<int> s1(new int(3));（もちろん必要ない）に変更すると、それも消えます。8行目から削除しても、セグメンテーション違反はありません。

したがって、害はありませんが、セグメンテーション違反が発生する理由がわかりません。私が理解している限り、
7行目では空のポインタがu1に割り当てられています。reset（）も、スコープの終わりもありません。それにもかかわらず、それi以降は無効のようです。それは意図されていますか？つまり、別のオブジェクトが破壊される可能性があるため、ポインタを移動するときは非常に注意する必要があります。

どう思いますか？どうすればこれから身を守ることができますか？

ありがとう、Steffen

-std = c ++ 0xオプションを使用して、gcc4.4.6でunique_ptrを有効にしました。それは非常にうまく機能しているようで、まさに私が必要としていたものです-カスタム削除機能を備えたスコープポインター。

しかし、私は問題に気づきました。

表示：ptr1は1を指しますptr2は1を指します

ostreamインサーターがbool値を挿入していると思います。

以下はそれを修正しますが、これが標準ライブラリの一部であってはならないのではないかと思います。

したがって、問題は次のとおりです。これは、gccでの現在のunique_ptr実装の制限ですか、それともunique_ptrに期待しすぎていますか？

私は次の（簡略化された）クラスを持っています：

Operand新しい作品を挿入しても問題ありません。ただし、関数が返されると、デストラクタが呼び出されるため、mapを呼び出すときにオブジェクトは含まれませんsetOperandsValue。私はDDDを使用してこれを観察しました：最後にinsertOperand Operator::~Operator()が呼び出されます。

std :: unique_ptrをSTLで使用することを確認した後、紹介しました（より良い：使用済み）std::moveが、正しく配置されていないか、何かが不足しています（知識不足が原因である可能性が高い）。利用できないので使用してmap::emplaceいません。

編集：デストラクタ呼び出しは、を破壊しているため、有効ですnew T(o)。とにかく、mapに入るときは空のままsetOperandsValueです。

編集＃2：結果を入力setOperandsValueして実行すると、つまり、以前に追加したのにエントリが見つかりません。op.find(o)op.end

次のような状況があります。

しかし、ポインターが2つのタイプのいずれかになる可能性があるため、変更する必要がありますが、これを行うと:

が範囲外であるため、コンパイルに失敗します。

私は試した

しかし、ベースからではなくメンバー関数を使用する必要があり、ベースクラスのコードにアクセスできないため、これは失敗します。

これを回避する優雅な方法があるに違いありませんが、私には見えませんよね？

私は VS2010 を使用していますが、ばかげたパフォーマンスの問題が見つかりました。上記のコードは、デバッグ ビルドとリリース ビルド (ctrl+f5) の両方でうまく機能しますが、デバッガーがアタッチされている場合 (f5)、unique_ptr クラスの dtor 呼び出しが耐えられないほど遅くなります。結果のマシン コードはかなり最適化されているため、デバッガーの問題ではなくコンパイラーの問題であるとは思いませんが、対処方法がわかりません。私の質問は

• この問題はあなたのマシンで再現できますか?
• この動作の理由は何ですか?
• 回避策はありますか？

std::unique_ptr::getそもそもunique_ptrを持つ目的を無効にしませんか? この関数が状態を変更して、ポインターを保持しないことを期待していました。std::unique_ptr::get の実際の有用な使用法はありますか?

私は、gcc 4.5.3 を使用している 2 人のエンド ユーザーと、gcc 4.6.3 に移動したばかりの 2 人のエンド ユーザーがいるライブラリに取り組んでいます。このライブラリは、新しい C++11 スマート ポインター (特に unique_ptr) を使用し、gcc 4.5.3 で正常にコンパイルされます。ただし、これらの 2 つのバージョンの間で、gcc は nullptr のサポートを開始したため、unique_ptr の API が変更され、標準により厳密に一致するようになりました。そうすることで、次のコードは問題ありませんでした。

nullptr の有無にかかわらず動作するように、上記の if ステートメントを変更するクリーンな (つまり、次の文の) 方法はありますか? 可能であれば、構成チェックを避けてから、次のようなマクロ（これでうまくいくと思います）を避けたいと思います

または、これが私が探している動作を取得する唯一の方法ですか?

Boostの場合と同様に、C++11はキャスト用のいくつかの関数を提供しますshared_ptr。

しかし、なぜに相当する関数がないのか疑問に思いますunique_ptr。

次の簡単な例を考えてみましょう。

この使用パターンが推奨されない理由はありますか？したがって、に存在するものと同等の機能shared_ptrが提供されていませんunique_ptrか？

現在、unique_ptr< Interface >&&コンストラクターでを受け入れるテスト中のクラスがあり、インターフェイス実装の単一の所有権を取得したいことを表現しています。ただし、モックを使用してこのクラスをテストする場合は問題が発生しInterfaceます。モックフレームワーク（HippoMocks）は、私Interface*が所有していないものだけを提供するため、削除できません。

以前、const shared_ptr< Interface >&引数としてクラスをテストするときに同じ問題が発生しましたが、カスタムのno-opdeleterを提供することで問題を修正しました。

削除者はテンプレート引数であるため、unique_ptrの同様の修正は実際には機能しません。

これに対する回避策はありますか？または、そもそもここでunique_ptrを使用するべきではありませんか？

更新 私はこれを試してみました。動作するはずですが、sizeof（ptr）は8になり、どのような影響があるかを判断するのは困難です。

私は G++ 4.7 でブリーディング エッジのセットアップをまとめました (ただし、現時点ではsudo apt-get boost-all-dev、Debian Wheezy に付属のブースト 1.48 をまだ使用しています)。

私のコードは、使用する論理データ構造がunique_ptrの多次元配列になる場所に設定されています。しかしmulti_array、unique_ptr が含まれている場合、空の単一要素の配列でさえ構築できないようです。したがって、これは機能します：

しかし、これはしません:

コンパイラからの関連する苦情は次のとおりだと思います。

/usr/include/c++/4.7/bits/stl_uninitialized.h:225: 'void std::uninitialized_fill_n(_ForwardIterator, _Size, const _Tp&) から必要 [with _ForwardIterator = std::unique_ptr*; _Size = unsigned int; _Tp = std::unique_ptr]'</p>

optional< unique_ptr<...> >ここで提供されているパッチを適用しても、いくつかの問題があります。

https://svn.boost.org/trac/boost/ticket/1841

( 注: Is it possible to move a boost::optional? で見つかりました)

たとえば、次のようになります。

自分のしていることは合法だと感じています。実際、unique_ptr をこのプロジェクトに組み込むことで、所有権の譲渡のセマンティクスに関していくつかのバグを既に発見しています。だから私は「ああ、これは複雑すぎる、生のポインタを使うだけだ」と言いたくありません。

これはブーストの議題でサポートするものですか? タイムラインはありますか？当面の間、使用できる簡単な回避策はありますか?