Uchwyty mieć odpowiednią semantykę inną niż wskazówki. Dla mnie taki przykład (wyodrębniony zZasada zero):

class module {
public:
    explicit module(std::wstring const& name)
    : handle { ::LoadLibrary(name.c_str()), &::FreeLibrary } {}

    // other module related functions go here

private:
    using module_handle = std::unique_ptr<void, decltype(&::FreeLibrary)>;

    module_handle handle;
};

za pomocąunique_ptr jako „własność w pakiecie” dla uchwytów jest złym przykładem. Po pierwsze, wykorzystuje wewnętrzną wiedzę, że uchwyt jest typem wskaźnika i używa tego do utworzeniaunique_ptr do podstawowego typu, na którym opiera się „nieprzezroczysty” typ uchwytu.

Uchwyty mogą być dowolnego typu, mogą być wskaźnikiem, mogą być indeksem lub wiedzą. Co najważniejsze, to, co masz pod ręką (na przykład z większości API C), to uchwyt i jego funkcja zwalniania zasobów.

Czy istnieje właściwa „własność w pakiecie”Prace w semantyce rękojeści? Mam na myśli, że już publicznie dostępny dla jednego?

Dla mnie,unique_ptr et. glin. nie działa, muszę zrobić niepotrzebne założenia na temat rodzaju uchwytujest, gdy chcę tylko uzyskać „własność w pakiecie” za pomocą nieprzezroczystego typu rękojeści i jej funkcji zwalniania.

Nie ma sensu, aby jeden wpatrywał się w typ uchwytu, aby tworzyć konstrukcje na podstawie tych informacji. To uchwyt, nie powinien mieć znaczenia.

Przytoczę tutaj uczucia innego użytkownika SOinne pytanie odpowiedź:

Stwórz specjalną klasę „inteligentnego wskaźnika”, która nie potrwa długo. Nie nadużywaj klas bibliotecznych. Semantyka uchwytów jest zupełnie inna niż w przypadku wskaźnika C ++; po pierwsze, wyłuskiwanie UCHWYTU nie ma sensu.

Jeszcze jeden powód, aby użyć niestandardowej klasy inteligentnego uchwytu - NULL, nie zawsze oznacza pusty uchwyt. Czasami jest to INVALID_HANDLE_VALUE, która nie jest taka sama.

Zrzeczenie się:

To pytanie przeformułowuje i opiera się na tym: