2010-09-01 19 views
5

Poza wszystkimi znanymi korzyściami używania auto_ptrs, jakie są "najgorsze praktyki" w auto_ptr?auto_ptr Pułapki i pułapki

  1. Tworzenie contempers STL auto_ptrs. Parametry auto_ptrs nie spełniają wymagań "CopyConstructable". Patrz „skuteczna STL” Również Scott Meyer, punkt 8.

  2. Tworzenie auto_ptrs tablic Upon zniszczenie, „Usuń” (a nie „delete []”), aby zniszczyć własność przedmiotu, więc ten kod plony auto_ptr za destruktor używa niezdefiniowane zachowanie: auto_ptr api (new int [42]);

  3. Nie dbanie o copy-ctor i op = w klasie za pomocą członków auto_ptr. Można naiwnie myśleć, że przy użyciu członków auto_ptr nie trzeba implementować operatora kopiowania/przypisania dla klasy. Jednak nawet jeden członek auto_ptr "zatruwa" klasę (tj. Narusza wymagania "CopyConstructable" i "Assignable"). Obiekty takich klas zostałyby częściowo uszkodzone podczas operacji kopiowania/przydziału.

Czy jest jeszcze więcej pułapek auto_ptr?

+0

Również, 'auto_ptr' będzie przestarzałe w następnym standardzie C++ (który Sutter ma nadzieję zostanie oficjalnie zatwierdzony po marcu 2011 r. (Http://herbsutter.com/2010/08/28/trip-report-august-2010 -iso-c-standards-meeting /), stając się C++ 0B dla nas, die-hards). Jeśli masz 'unique_ptr', użyj go zamiast tego. –

Odpowiedz

6

Nie jestem pewien, czy jest to pułapka/pułapka, ale to na pewno mniej niż oczywiste:

  • const auto_ptr nie może mieć jego własności zawartych wskaźnik przeniesiona

Innymi słowy:

const auto_ptr<Foo> ap(new Foo()); 
auto_ptr<Foo> ap2; 

ap2 = ap; // Not legal! 

to jest w rzeczywistości całkiem przydatna jeśli chcesz wziąć argument auto_ptr i Gu arantee, że nie będziesz przejmować własności zawartego wskaźnika, ale może to być również zaskakujące, jeśli oczekujesz, że const auto_ptr<Foo> zachowuje się jak Foo const*.

Powiązane problemy