Używanie inteligentnych wskaźników dla członków klasy

Mam problem ze zrozumieniem użycia inteligentnych wskaźników jako członków klasy w C ++ 11. Dużo czytałem o inteligentnych wskazówkach i myślę, że rozumiem, jak unique_ptri shared_ptr/ weak_ptrdziała ogólnie. To, czego nie rozumiem, to prawdziwe użycie. Wygląda na to, że wszyscy zalecają używanie unique_ptrgo prawie cały czas. Ale jak bym zaimplementował coś takiego:

class Device {
};

class Settings {
    Device *device;
public:
    Settings(Device *device) {
        this->device = device;
    }

    Device *getDevice() {
        return device;
    }
};    

int main() {
    Device *device = new Device();
    Settings settings(device);
    // ...
    Device *myDevice = settings.getDevice();
    // do something with myDevice...
}

Powiedzmy, że chciałbym zastąpić wskaźniki inteligentnymi wskazówkami. A unique_ptrnie zadziała z powodu getDevice(), prawda? Więc to jest czas, kiedy używam shared_ptri weak_ptr? Nie ma możliwości korzystania unique_ptr? Wydaje mi się, że w większości przypadków shared_ptrma to większy sens, chyba że używam wskaźnika w naprawdę małym teleskopie?

class Device {
};

class Settings {
    std::shared_ptr<Device> device;
public:
    Settings(std::shared_ptr<Device> device) {
        this->device = device;
    }

    std::weak_ptr<Device> getDevice() {
        return device;
    }
};

int main() {
    std::shared_ptr<Device> device(new Device());
    Settings settings(device);
    // ...
    std::weak_ptr<Device> myDevice = settings.getDevice();
    // do something with myDevice...
}

Czy to jest droga? Dziękuję bardzo!

A unique_ptrnie zadziała z powodu getDevice(), prawda?

Nie, niekoniecznie. Ważne jest tutaj określenie odpowiedniej polityki własności dla twojego Deviceobiektu, tj. Kto będzie właścicielem obiektu wskazywanego przez twój (inteligentny) wskaźnik.

Czy będzie to instancja Settingsobiektu sam ? Czy Deviceobiekt będzie musiał zostać zniszczony automatycznie, gdy Settingszostanie zniszczony, czy też powinien przeżyć ten obiekt?

W pierwszym przypadku std::unique_ptrjest to, czego potrzebujesz, ponieważ staje Settingssię jedynym (unikalnym) właścicielem wskazanego przedmiotu i jedynym obiektem odpowiedzialnym za jego zniszczenie.

Przy takim założeniu getDevice()powinien zwrócić prosty wskaźnik obserwacyjny (wskaźniki obserwacyjne to wskaźniki, które nie utrzymują wskazanego obiektu przy życiu). Najprostszym rodzajem wskaźnika obserwacyjnego jest wskaźnik surowy:

#include <memory>

class Device {
};

class Settings {
    std::unique_ptr<Device> device;
public:
    Settings(std::unique_ptr<Device> d) {
        device = std::move(d);
    }

    Device* getDevice() {
        return device.get();
    }
};

int main() {
    std::unique_ptr<Device> device(new Device());
    Settings settings(std::move(device));
    // ...
    Device *myDevice = settings.getDevice();
    // do something with myDevice...
}

[ UWAGA 1: Możesz się zastanawiać, dlaczego używam tutaj wskaźników surowych, kiedy wszyscy powtarzają, że wskaźniki surowe są złe, niebezpieczne i niebezpieczne. W rzeczywistości jest to cenne ostrzeżenie, ale ważne jest, aby umieścić je w odpowiednim kontekście: surowe wskaźniki są złe, gdy są używane do wykonywania ręcznego zarządzania pamięcią , tj. Przydzielania i zwalniania obiektów za pomocą newi delete. Kiedy używa się go wyłącznie jako środka do osiągnięcia semantyki referencyjnej i przekazywania nie-posiadania, obserwowania wskaźników, nie ma nic z natury niebezpiecznego w surowych wskaźnikach, może z wyjątkiem faktu, że należy uważać, aby nie wyłuskać wiszącego wskaźnika. - UWAGA KOŃCOWA 1 ]

[ UWAGA 2: Jak okazało się w komentarzach, w tym konkretnym przypadku, gdy własność jest unikalna, a posiadany obiekt jest zawsze obecny (tj. Wewnętrzny element danych devicenigdy nie będzie nullptr), funkcja getDevice()mogłaby (i być może powinna) zwraca raczej odwołanie niż wskaźnik. Chociaż to prawda, zdecydowałem się zwrócić tutaj surowy wskaźnik, ponieważ chciałem, aby była to krótka odpowiedź, którą można uogólnić na przypadek, w którym devicemoże być nullptr, i pokazać, że surowe wskaźniki są w porządku, o ile nie używa się ich do ręczne zarządzanie pamięcią. - UWAGA KOŃCOWA 2 ]

Sytuacja jest oczywiście radykalnie inna, jeśli twój Settingsprzedmiot nie powinien mieć wyłącznej własności urządzenia. Może tak być na przykład w przypadku, gdy zniszczenie Settingsprzedmiotu nie powinno oznaczać również zniszczenia wskazanego Deviceprzedmiotu.

To jest coś, co tylko Ty jako projektant swojego programu możesz powiedzieć; z podanego przez ciebie przykładu trudno mi stwierdzić, czy tak jest, czy nie.

Aby pomóc ci to zrozumieć, możesz zadać sobie pytanie, czy istnieją inne obiekty oprócz tych, Settingsktóre są uprawnione do utrzymywania Deviceobiektu przy życiu, o ile trzymają na nim wskaźnik, zamiast być biernymi obserwatorami. Jeśli tak jest, potrzebujesz polityki współwłasności , która std::shared_ptrzapewnia:

#include <memory>

class Device {
};

class Settings {
    std::shared_ptr<Device> device;
public:
    Settings(std::shared_ptr<Device> const& d) {
        device = d;
    }

    std::shared_ptr<Device> getDevice() {
        return device;
    }
};

int main() {
    std::shared_ptr<Device> device = std::make_shared<Device>();
    Settings settings(device);
    // ...
    std::shared_ptr<Device> myDevice = settings.getDevice();
    // do something with myDevice...
}

Zwróć uwagę, że weak_ptrjest to wskaźnik obserwujący , a nie wskaźnik będący właścicielem - innymi słowy, nie utrzymuje on przy życiu wskazanego obiektu, jeśli wszystkie inne wskaźniki będące właścicielami wskazanego obiektu wykraczają poza zakres.

Przewaga weak_ptrnad regularnym surowego wskaźnik jest to, że można bezpiecznie powiedzieć, czy weak_ptrjest zwisające czy nie (czyli czy jest wskazując ważnego obiektu, lub jeśli obiekt pierwotnie wskazał został zniszczony). Można to zrobić, wywołując expired()funkcję składową na weak_ptrobiekcie.

class Device {
};

class Settings {
    std::shared_ptr<Device> device;
public:
    Settings(const std::shared_ptr<Device>& device) : device(device) {

    }

    const std::shared_ptr<Device>& getDevice() {
        return device;
    }
};

int main()
{
    std::shared_ptr<Device> device(new Device());
    Settings settings(device);
    // ...
    std::shared_ptr<Device> myDevice(settings.getDevice());
    // do something with myDevice...
    return 0;
}

week_ptrjest używany tylko dla pętli referencyjnych. Graf zależności musi być grafem skierowanym acyklicznie. We wspólnych wskaźnikach istnieją 2 liczniki odwołań: 1 dla shared_ptrs i 1 dla wszystkich wskaźników ( shared_ptri weak_ptr). Po shared_ptrusunięciu wszystkich znaków wskaźnik jest usuwany. Gdy potrzebny jest wskaźnik from weak_ptr, lockpowinien zostać użyty do pobrania wskaźnika, jeśli istnieje.