ニコライJosuttis氏は、彼の著書「C++標準ライブラリ - チュートリアルとリファレンス」には、44ページで、次の段落の書き込み：auto_ptrsの概念によるとauto_ptrへの定数参照を期待する関数にauto_ptrを渡す危険はありますか？
を、に所有権を移転することが可能です定数参照を使って関数を呼び出す。これは非常に危険です。なぜなら、オブジェクトは、定数参照として渡すとオブジェクトが変更されないことを通常期待しているからです。幸運なことに、auto_ptrsの危険性を低くした設計の遅れがありました。いくつかのトリッキーな実装技術によって、一定の参照で所有権の移転は不可能です。実際には、定数auto_ptr：＆hellip;の所有権を変更することはできません。
定数参照を使用して所有権を変更できない場合、上記の「これは非常に危険です」と「危険性がより低い」という表現がなぜなのですか？コメントを合計
：
「これは非常に危険ですが、」std::auto_ptr<>のコピーコンストラクタ（所有権を転送します）を意味し、これはconst-correctnessの完全な違反であるconst参照引数–を取りました。
「危険性がより低い」とは、コピーコンストラクタ（現在は非const参照）が所有権を全く移すことができないということです。これはまだ危険です。ただとしてとしてコピーコンストラクタがconst参照を取ったときに危険です。
std::auto_ptr<>というこの側面は、普遍的に使用できないほど壊れているとみなされる限り、一般的にクラスの欠陥とみなされます。その結果、
boost::scoped_ptr<>と
boost::shared_ptr<>は、C++ 03の「実際の」スマートポインタとみなされ、C++ではstd::auto_ptr<>は廃止され、std::unique_ptr<>が推奨されます（完全にC++では削除されました）。
更新：boost::movelib::unique_ptr<>：、Boost.Moveライブラリは今boost::scoped_ptr<>ではなく、使用されるべきであるstd::unique_ptr<>のC++ 03のエミュレーションを提供しブースト1.57の通り。
"' 'std :: auto_ptr <>'のこの側面は、普遍的にクラス "：私は同意しません。あなたがしていることを知っている限り、それはいいです。移動セマンティクスがなければ、関数から参照されていないスマートポインタを返すことは不可能*です。 'std :: auto_ptr <>'はその問題を回避します。はい、それはそうするために "コピー"の概念を破るが、それは言語が提供したものなので、それが唯一の選択肢だった。 'unique_ptr'にアクセスできたら' auto_ptr'を削除してください。しかし、それがどのように動作するかを認識している限り、完全に使用可能です。 –
@ニコル：そのセマンティクスが不明確である（そして標準ライブラリの残りの部分に反する）という事実は欠陥ではない？ ; - ]エラーが発生する可能性のあるトランプは私の本で "使用可能"です - 'std :: shared_ptr <>'や 'std :: unique_ptr <>'の使い方を壊すのは難しいですが、 '' std :: auto_ptr <> 'を参照してください。 – ildjarn
auto_ptrをunique_ptrのように扱うことは私の仕事です。そうでなければ、私はそれを避けようとします。 –
彼はconst参照でオーナーシップを変更することはできませんでした。 – ildjarn
@ildjarnしかし、この文はどうでしょうか？「幸いにも、auto_ptrs **の危険性を低くしたデザイン決定が遅れました**」 – Belloc
そうです、彼らはconst参照で所有権を変更することはできませんでした。なぜあなたはなぜそれほど危険ではないのかを尋ねていますか？ – ildjarn