Il est là au cas où vous pouvez convertir implicitement les pointeurs:
struct base {};
struct derived : base {};
std::auto_ptr<derived> d(new derived);
std::auto_ptr<base> b(d); // converts
En outre, vous n'avez pas demandé, mais vous remarquerez que le constructeur de copie est non-const. C'est parce que le auto_ptr
prendra possession du pointeur. Dans l'exemple ci-dessus, après b
est construit, d
tient à rien. Cela rend auto_ptr
impropre à l'utilisation dans des conteneurs, car il ne peut pas être copié.
C++ 0x fossés auto_ptr
et en fait un appelé unique_ptr
. Ce pointeur a les mêmes objectifs, mais les accomplit correctement à cause de la sémantique des déplacements. Autrement dit, alors qu'il ne peut pas être copié, il peut « déplacer » la propriété:
std::unique_ptr<derived> d(new derived);
std::unique_ptr<base> b(d); // nope, cannot be copied
std::unique_ptr<base> b(std::move(d)); // but can be moved
Cela rend unique_ptr
adapté à une utilisation dans des conteneurs, parce qu'ils ne copient plus leurs valeurs, ils les déplacent.
Le titre de cette question doit être changé en "Pourquoi l'interface de auto_ptr spécifie-t-elle deux constructeurs de type copy-constructor?" – Omnifarious
fait, j'étais confus quand j'ai vu cette interface et ne pouvais pas penser à un bon titre :) –