タイトルは私の質問をほぼ要約しています。ヌルポインタをチェックするために次のことができないのはなぜですか?
auto_ptr<char> p( some_expression );
// ...
if ( !p ) // error
代わりにこれを行う必要があります。
if ( !p.get() ) // OK
なぜauto_ptr<T>単純にoperator!()定義していないのですか?
その設計に誤りがあったようです。これはC++0xで修正されます。unique_ptr(の置換auto_ptr)が含まれていますexplicit operator bool() const;
新しいC++標準からの引用:
クラステンプレートauto_ptrは非推奨になりました。[注:クラステンプレートunique_ptr(20.9.10)は、より優れたソリューションを提供します。—エンドノート]
いくつかの説明:
Q:何が問題になっていa.get() == 0ますか?
A:に問題はありませんがa.get()==0、スマートポインターを使用すると、実際のポインターであるため、それらを操作できます。追加operator bool()はあなたにそのような選択を与えます。auto_ptr非推奨にする本当の理由は、直感的なデザインがないからだと思います。しかしoperator bool、unique_ptr新しい規格では、それを持たない理由がないことを意味します。
operator !()簡単に言えば、それは定義されているはずです。auto_ptrあまりよく設計されたコンテナではありません。boostのスマートポインターには、operator bool()で否定できる変換演算子が定義されていoperator !()ます。これにより、if(!p)コンパイルと期待どおりの動作が可能になります。
ブール変換に問題があります。これにより、ほとんどの場合面倒な構文が可能になります。
幸いなことに、解決策があります。SafeBoolイディオムです。
への変換の問題boolは、暗黙の変換が危険であるということです。
std::auto_ptr<T> p = ..., q = ....;
if (p < q) // uh ?
したがって、operator bool() const忌まわしいです。明示的な方法を提供するか、安全なブールイディオムを使用します。
このイディオムの考え方は、操作のサブセットが非常に少ないタイプのインスタンスを提供することであり、暗黙の変換によって問題が発生することはほとんどありません。これは、メンバー関数へのポインターを使用して行われます。
のような操作は意味がありif (p)ますが、コンパイルに失敗します。if (!p)if (p < q)
完全な解決策については、リンクをよく読んでください。そうしないと、なぜ持っていないのが良いのかがわかりますoperator bool() const。
sをnullに渡すauto_ptrことはまれなケースであると予想されたため、余分なインターフェイスの追加を回避し、実際にnullをチェックするときに明示的にするためだと思います。