Jakiego rodzaju wskaźnika użyć kiedy?

Decydowanie, jakiego inteligentnego wskaźnika użyć, jest kwestią własności. Jeśli chodzi o zarządzanie zasobami, obiekt a jest właścicielem obiektu B, jeśli kontroluje czas życia obiektu B. na przykład zmienne członkowskie są własnością ich odpowiednich obiektów, ponieważ czas życia zmiennych członkowskich jest związany z Czasem Życia obiektu. Inteligentne Wskaźniki wybiera się na podstawie tego, jak obiekt jest własnością.

Zauważ, że własność w systemie oprogramowania jest odrębna od własności jako myślimy o tym poza oprogramowaniem. Na przykład osoba może "posiadać" swój dom, ale nie musi to oznaczać, że obiekt Person ma kontrolę nad czasem życia obiektu House. Połączenie tych rzeczywistych pojęć z pojęciami oprogramowania jest pewnym sposobem zaprogramowania się w dziurę.

Jeśli posiadasz wyłączną własność obiektu, użyj std::unique_ptr<T>.

Jeśli posiadasz współwłasność obiektu...
- Jeśli nie ma cykli w posiadaniu, użyj std::shared_ptr<T>.
- Jeśli są cykle, zdefiniuj "kierunek" i użyj std::shared_ptr<T> w jednym kierunku i std::weak_ptr<T> w drugim.

Jeśli obiekt jest twoją własnością, ale istnieje możliwość braku właściciela, użyj zwykłych wskaźników T* (np. wskaźników nadrzędnych).

Jeśli obiekt jest twoją własnością (lub w inny sposób ma zagwarantowane istnienie), użyj referencji T&.

Uwaga: Należy pamiętać o kosztach inteligentnych wskaźników. W środowiskach o ograniczonej pamięci lub wydajności korzystne może być użycie normalnego wskaźniki z bardziej ręcznym schematem zarządzania pamięcią.

Koszty:

• Jeśli masz niestandardowy deleter (np. używasz puli alokacji), spowoduje to obciążenie na wskaźnik, którego można łatwo uniknąć przez ręczne usunięcie.
• std::shared_ptr mA narzut przyrostu liczby referencji przy kopiowaniu, plus zmniejszenie przy niszczeniu, a następnie sprawdzenie zliczania 0 z usunięciem przechowywanego obiektu. W zależności od implementacji może to wydmuchać Twój kod i spowodować problemy z wydajnością.
• czas kompilacji. Podobnie jak w przypadku wszystkich szablonów, Inteligentne Wskaźniki negatywnie wpływają na czas kompilacji.

Przykłady:

struct BinaryTree
{
    Tree* m_parent;
    std::unique_ptr<BinaryTree> m_children[2]; // or use std::array...
};

Drzewo binarne nie posiada swojego rodzica, ale istnienie drzewa implikuje istnienie jego rodzica (lub nullptr dla roota), więc używa zwykłego wskaźnika. Drzewo binarne (z semantyką wartości) ma wyłączną własność swoich dzieci, więc są to std::unique_ptr.

struct ListNode
{
    std::shared_ptr<ListNode> m_next;
    std::weak_ptr<ListNode> m_prev;
};

Tutaj węzeł listy posiada swój następny i poprzedni listy, więc definiujemy kierunek i używamy shared_ptr dla next i weak_ptr dla prev, aby przerwać cykl.

Używaj unique_ptr<T> cały czas, z wyjątkiem sytuacji, gdy potrzebujesz zliczania referencji, w którym to przypadku użyj shared_ptr<T> (a w bardzo rzadkich przypadkach, weak_ptr<T>, aby zapobiec cyklom referencyjnym). W prawie każdym przypadku przenoszenie unikalnej własności jest w porządku.

Raw pointers: dobre tylko wtedy, gdy potrzebujesz kowariantnych zwrotów, które mogą się zdarzyć bez posiadania wskazań. Inaczej nie są zbyt przydatne.

Wskaźniki tablicy: unique_ptr ma specjalizację dla T[], która automatycznie wywołuje delete[] na wyniku, dzięki czemu można na przykład bezpiecznie wykonaj unique_ptr<int[]> p(new int[42]);. shared_ptr nadal potrzebujesz niestandardowego deletera, ale nie potrzebujesz specjalistycznego współdzielonego lub unikalnego wskaźnika tablicy. Oczywiście takie rzeczy zazwyczaj najlepiej zastąpić std::vector. Niestety shared_ptr nie zapewnia funkcji dostępu do tablicy, więc nadal musisz ręcznie wywołać get(), ale unique_ptr<T[]> dostarcza operator[] zamiast operator* i operator->. W każdym razie musisz sprawdzić sam. To sprawia, że shared_ptr jest nieco mniej przyjazny dla użytkownika, chociaż prawdopodobnie ogólny przewaga i brak zależności Boost czyni unique_ptr i shared_ptr ponownie zwycięzcami.

Wskaźniki zakresowe: nieistotne przez unique_ptr, tak jak auto_ptr.

Nadal istnieją zastosowania dla innych inteligentnych wskaźników, takich jak intrusive_ptr lub interprocess_ptr. Jednak są one bardzo niszowe i całkowicie niepotrzebne w ogólnym przypadku.

Przypadki kiedy używać unique_ptr:

• metody fabryczne
• Członkowie, którzy są wskaźnikami (w tym pimpl)
• Przechowywanie wskaźników w kontenerach stl (aby uniknąć ruchów)
• użycie dużych lokalnych obiektów dynamicznych

Przypadki kiedy używać shared_ptr:

• współdzielenie obiektów między wątkami
• dzielenie obiektów w ogóle

Przypadki kiedy używać weak_ptr:

• Duża mapa, która działa jako ogólne odniesienie (ex. mapa wszystkich otwartych gniazda)

Zapraszam do edycji i dodawania kolejnych