Discussion :

[Matthieu Brucher]

C'est pas indispensable, mais c'est super super pratique pour gérer les fuites mémoire, c'est pour ça que des pointeurs intelligents ont été rajouté dans TR1. C'est sûr, ce sont des objets, mais presque comme des pointeurs normaux, mais pas tout à fait

[Charlemagne]

Oui, c'est très très pratique dans certains cas.

J'ai fait ma propre implémentation car je trouvais (à l'époque, y'a 5-6 ans) celle de boost mal faite. Je sais pas comment elle est aujoourd'hui.
Mais personnellement je ne les ai quasiment jamais utilisés.

C'est vrai que c'est un trou/oubli dans la STL, et je comprends pas pourquoi les créateurs (Stroustrup?) n'y ont pas pensé. L'auto_ptr est tout juste bon pour convertir vite fait bien fait du C en C++, et autoriser ainsi les exceptions.

La STL (et le C++) vise la disparition totale des pointeurs. Tout pointeur est un bug potentiel si une exception est jettée avant sa désallocation (vrai également pour toute resource: mémoire, fichier...).
Et donc TOUT pointeur non encapsulé est à proscrire, et tout pointeur est à éviter.

[JolyLoic]

A l'époque de la norme, je pense que tout simplement, la notion de pointeur intelligents n'était pas si évidente. Il ne faut pas oublier qu'elle a été décidée globalement en 96, et qu'à l'époque, par exemple, les gens commençaient juste à jouer avec les exceptions voir ce qu'on pourrait en tirer.

[Matthieu Brucher]

En fait, plusieurs s'y étaient attaqués et avaient proposé leur version, mais elles n'étaient pas assez robustes - voir les commentaires de Meyers à ce sujet dans Effective C++ et de Alexandrescu dans Modern C++ Design -. Maintenant qu'une autre version est dans TR1 - shared_ptr et weak_ptr -, on peut se faire plaisir.
En revanche, ce qui est dommage c'est qu'entre les différentes classes, tout n'est pas identique - plus ou moins de typedef et de fonctions externes -