問題タブ [auto-ptr]

現在、取り組んでいるプロジェクトの cml ( http://www.cmldev.net/ ) 数学ライブラリの基本的なラッパーを作成しようとしています。1 つのプライベート メンバーを持つ cml ベクトル クラスのラッパーがあります。

(サイズを抑えるために、コンストラクターの実装を省略したことに注意してください)

別のファイルでは、いくつかの #defines を使用して言葉を簡単にしています。

Vector3f を使用しようとすると、問題が発生するようになりました

エラーが表示されます：

「コンストラクター 'Math::Vector3::Vector3 [with T = float]' のインスタンスが引数リストに一致しません」

auto_ptrテンプレートに問題がある場合に備えて、通常のポインターに変更しようとしましたが、を使用せずに変数を宣言しようとしたところ#define、同じ問題が発生しました。実装でそのコンストラクターを確認できるため、ここに何かが欠けています。

クラスがあれば

C のコピー コンストラクターを定義するにはどうすればよいですか。

まさか

auto_ptr を other からコピーしたいので、所有権を削除して other を変更しました。コピーコンストラクターを次のように定義することは合法ですか?

タイトルは私の質問をほぼ要約しています。ヌルポインタをチェックするために次のことができないのはなぜですか？

代わりにこれを行う必要があります。

なぜauto_ptr<T>単純にoperator!()定義していないのですか？

私は現在、2D ゲーム エンジンに取り組んでおり、auto_ptr と、それらを標準コンテナーに入れてはならない方法について読みました。

私のエンジンはこの構造を持っています：

StateManager -- 多くあります --> State です。

状態は、エンジンの外側のメインで作成され、割り当てられます。コマンドで状態を変更できるように、エンジンにすべての状態のリスト/ベクトルを保存してもらいたいです。

例えば：

アプリケーションが終了したときにのみ状態が終了するため、このアプローチを使用できますか?

StateManager は、状態へのポインターのベクトルのみを維持する必要があり、所有権を取得する必要はありません。エンジンの状態を変更したい場合は、activeState ポインターを変更して、stateList ベクトルにある目的の状態を指すようにします。

これは悪いアプローチですか？

誰でもC++リファレンスサイトからこのコードを説明できますか:

編集:私は言及すべきでした.Boostのドキュメントをptr_sequence_adapter見ていましたが、それらのアダプターtemplate< class U > void push_back( ::std::auto_ptr<U> x );は実行と同等でvec.push_back(autoPtr.release());あり、強力な例外保証も提供すると主張しています. そして、実装が実際に何であったかについて、実装の効果に関する彼らの説明を混同していることに気付きました。したがって、この質問はほとんど無意味です。後世のためにここに残しておきます。

私には、への呼び出しstd::auto_ptr<t>が成功し、への呼び出しがstd::vector<t*>::push_back例外をスローし、ポインターがリークする可能性があるようです。

代わりにこれを行う必要があるようです：

コードベースで最近見た次のコード例を考えてみてください。

私はこれが好きではありません - そしてむしろそう書きたいです：

しかし、それは本当に問題ですか？

新しい標準（および一部のコンパイラですでに利用可能な部分）が登場すると、新しいタイプstd::unique_ptrはの代わりになるはずですstd::auto_ptr。

それらの使用法は正確に重複していますか（コードでグローバルな検索/置換を実行できます（これを実行するわけではありませんが、実行した場合））、またはドキュメントを読んでも明らかではないいくつかの違いに注意する必要がありますか？

また、それが直接の置き換えである場合、単に改善するのではなく、なぜ新しい名前を付けるのstd::auto_ptrですか？

auto_ptr を使用する既知のすべての利点に加えて、auto_ptr の「ワースト プラクティス」とは何ですか?

1. auto_ptrs の STL コントレーナーの作成。auto_ptrs は「CopyConstructable」要件を満たしていません。Scott Meyer の「Effective STL」の項目 8 も参照してください。

2. 配列の auto_ptr の作成 破棄時に、auto_ptr のデストラクタは「delete」を使用して (決して「delete[]」は使用しない)、所有しているオブジェクトを破棄するため、このコードは未定義の動作を引き起こします。

3. auto_ptr メンバーを使用するクラスで copy-ctor と op= を処理しない。auto_ptr メンバーを使用することで、クラスのコピー コンストラクター/代入演算子を実装する必要がないと素朴に考えるかもしれません。ただし、単一の auto_ptr メンバーでさえ、クラスを「毒殺」します (つまり、「CopyConstructable」および「Assignable」の要件に違反します)。このようなクラスのオブジェクトは、コピー/割り当て操作中に部分的に破損します。

他にも auto_ptr の落とし穴はありますか?

auto_ptrC++11では非推奨になると聞きました。これの理由は何ですか？

また、との違いを知りたいauto_ptrですshared_ptr。