vector に格納された auto_ptr を含む Classへのフォローアップとして、コピーの構築とコピーの代入の両方auto_ptr
がユーザー定義である限り、コンテナー要素としてメンバーを持つクラスを使用しても問題ないという明言されていない結論があると思います(そうしないように) s コピー コンストラクターとコピー代入を呼び出します)。これについて、標準ライブラリの要件に違反するものはありますか?auto_ptr
慣用的にやり始めたいので、次の点に問題がある場合は教えてください。
#include <memory>
#include <algorithm>
class Y { /* ... */ };
class Z : public Y { /* ... */ };
class X {
public:
X() : ap(new Z()) {}
X(const X& other) : ap(other.ap->clone()) {}
X& operator=(X other) { swap(other); return *this; } // any problem with swap?
void swap(X& other) { std::swap(ap, other.ap); }
// note no destructor necessary
private:
std::auto_ptr<Y> ap; // Y provides clone()
};
私が気づいたことの 1 つは、このアプローチでは、Y
のクラス定義が の定義のスコープ内にある必要があることですX
(「生の」ポインタY
が使用されている場合に前方宣言されるのとは対照的に)。これは、auto_ptr
がインスタンス化されるときに、そのデストラクタが で delete を呼び出す必要があり、不完全な型であってはならないY
ためです。クラスが複数のリソースを管理する(複数のメンバーを持つ)Y
場合、これは RAII の値と比較検討する必要があると思います。これについて何か考えはありますか?X
auto_ptr
この手法は全体的に優れていると思います。潜在的に複数のリソース (単一責任プリンシパル) を構築/破棄/コピーする必要があるクラスの多くのトリッキーなコードを排除するためです。auto_ptr
目的を果たしているかどうか、または言語/標準ライブラリの微妙な要件のためにここで機能しないかどうか疑問に思っています。
私は他のタイプのスマート ポインターを認識していますが、ライブラリ インターフェイスを実装しているので、クライアントに Boost や TR1 の要件を課したくないことに注意してください。一般的なの使用に関する講義はすべてauto_ptr
反対票を投じられます!