Ten wpis jest skierowany do nowicjuszy i jest odpowiedzią na nagminną praktykę uczenia C++ jako C with classes (witamy w roku 1984), skutkującą potem zalewem kodu fatalnej jakości na wszelkiej maści forach.

Kiedy? NIGDY!

Ok, jest to pewne uproszczenie i są od tej reguły wyjątki. Ale chciałbym wyraźnie przekazać, że to użycie new jest odstępstwem od reguły, a nie odwrotnie. W przypadku delete takich wyjątków nie ma wcale.

To jak mam utworzyć obiekt?

C++ to nie Java. Poniższy kod nie jest niejawną definicją wskaźnika na Foo, tylko obiektu tego typu:

Foo foo;

Tutaj wstawię link do wyjaśnienia czym jest wskaźnik/referencja/obiekt/klasa, gdy takie napiszę.

Chcę mieć tablicę o rozmiarze nieznanym w czasie kompilacji

Super. Od tego jest std::vector. Dodatkowo dzięki RAII nie musisz martwić się o zwolnienie zasobów (zero- lub wielokrotne).

int* arr = new T[n];
for(int i = 0; i < n; ++i) {
    arr[i] = process(i);
}
display(arr, n);
delete[] arr;

W powyższym kodzie, jeśli display lub process rzuci wyjątek, pamięć arr wycieknie. Jeśli w procesie refaktoringu zostanie dodane nowe wyjście z funkcji, programista będzie musiał pamiętać aby dodać odpowiednią komendę delete[]. Wszystko to jest zbędne, gdy pozwolisz kompilatorowi się wyręczyć za sprawą RAII. Analogiczne użycie std::vector może wyglądać następująco:

std::vector<int> arr(n);
for(int i = 0; i < n; ++i) {
    arr[i] = process(i);
}
display(arr, n);

Opisane wyżej problemy go nie dotyczą.

A co jeśli chcę mieć dostęp do tego samego obiektu z wielu miejsc/obiekt jest duży i jego wielokrotne kopiowanie jest złe?

Nic nie stoi na przeszkodzie, aby przekazać referencję albo wskaźnik do obiektu o automatycznym czasie życia (kolokwialnie: znajdującego się na stosie). Można tez użyć std::unique_ptr/std::shared_ptr wraz z std::make_unique/std::make_shared.

Najistotniejszą sprawą jest jasne określenie kto, gdzie i w jaki sposób odpowiada za czas życia, a więc i usunięcie obiektu. W większości przypadków wystarczy automatyczny czas życia, czyli “zwykła zmienna” i to powinno być rozwiązanie domyślne:

void process_ptr(Foo const*);
void process_ref(Foo const&);
 
// ...
Foo foo;
 
process_ptr(&foo);
process_ref(foo);

Jeśli z jakiegoś powodu nie jest możliwe użycie takiego sposobu, pierwszą alternatywą powinien być std::unique_ptr. Może tak być np. jeśli chcemy dynamicznie zadecydować o typie obiektu lub jeśli jakieś API zwraca wskaźnik do obiektu, za którego usunięcie odpowiada użytkownik:

void process_ptr(Widget const*);
void process_ref(Widget const&);
 
// ...
std::unique_ptr<Widget> someWidget{createSomeWidget()};
 
process_ptr(someWidget.get());
process_ref(*someWidget);

Dopiero gdy użycie std::unique_ptr okaże się niemożliwe powinien zostać rozważony std::shared_ptr. Dzieje się tak najczęściej gdy nie ma jasno określonego czasu życia obiektu. Pozwala on na utrzymanie go przy życiu dopóki istnieje chociaż jeden std::shared_ptr na dany obiekt.

Ten wybór, wraz z życiowymi przykładami został fantastycznie przedstawiony przez Herba Suttera na ostatnej konferencji C++Con:

Ok, to kiedy mogę użyć new?

Znam dwa akceptowalne powody:

Używasz jakiegoś frameworka/biblioteki, który to wymusza

Np. Qt, gdzie częstym widokiem jest:

QSomeWidget* w = new QSomeWidget(this);

Należy jednak zauważyć, że w powyższym przypadku QWidget przejmuje odpowiedzialność za zwolnienie zaalokowanego obiektu w odpowiednim momencie. Nie ma więc potrzeby samodzielnego wywoływania delete.

make_shared/make_unique nie jest w stanie skonstruować obiektu

Jest tak np. dla agregatów (w pewnym uproszczeniu klasa lub tablica klas bez konstruktorów niedomyślnych, zawierająca tylko publiczne elementy), które trzeba inicjalizować za pomocą {}. Dlatego poniższy kod jest akceptowalny:

struct person
{
    std::string name;
    int number_of_hands;
};
 
auto ptr = std::unique_ptr<person>(new person{"Jan Kowalski", 2});

A delete?

Nigdy. Serio, we wszystkich wyżej opisanych przypadkach nie ma potrzeby ręcznego pisania delete. Jeśli Twój kod jest napisany w taki sposób, że jest to niezbędne – robisz coś źle.

A co jeśli nie jestem nowicjuszem?

W takim wypadku wszystko powyższe powinieneś już wiedzieć i stosować. Jedyne dodatkowe przypadki, gdzie sensowne jest ręczne użycie new to implementacja własnych kontenerów/smart pointerów lub alokatorów (wtedy również ma sens użycie delete) lub placement new. Ewentualnie new (std::nothrow) T jako argument konstruktora smart pointera.

Podsumowując

Użycie nagich new/delete jest niezalecane. Jeśli jesteś nowicjuszem: stosuj się do tych rad. W przeciwnym wypadku zdaj się na własne doświadczenie. Temat ten poruszyłem także w tym artykule.