Oto artykuł, który mówi o nazwie idiomuZasada zero.

Oto fragment:

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;
};

Ponownie używaunique_ptr Funkcje RAII, więc nie musisz przejmować się wprowadzaniem zniechęcającej i gadatliwej reguły rządzącej piątką.

Przedstawiony w ten sposób (zarządzanie zasobami opartymi na uchwytach za pomocąunique_ptr, w ten sposób), wygląda to dla mnie jak hack, a nie najlepsze rozwiązanie dla tego, co próbuje rozwiązać. Zakłada się domyślnie zbyt wiele założeń:

Można przeglądać i używać podstawowego typu#define (lubtypedef) HANDLE jest zbudowany na. Dla mnie powinna to być wiedza ukryta, a rozwiązanie oparte wyłącznie na tym, co udostępnia interfejs:HANDLE.Uchwyty, mogą być czymkolwiek, nie muszą być typami wskaźników.

Chciałbym użyć tego idiomu, ale w wielu sytuacjach nie trafiam.

Czy to jestuchwyt skupia opakowanie RAII już zrobione i użyteczne w jakiejś fajnej bibliotece? Czy wszyscy używają takiego narzędzia i nie wiem? (Myślę, że miło jest mieć takie narzędzia nie tylko dla jednego, ale dla wielu rodzajów własności, które są)

EDYTUJ 1

Nie dotyczy to uchwytów zasobów specyficznych dla platformy, np.glGenLists zwraca rodzaj uchwytu, to jestGLuinti powinieneś zadzwonićglDeleteLists na tym. Jak już powiedziano, uchwyty zasobów nie muszą być typami wskaźników i nie należy zakładać tego założenia.

EDYCJA 2

Zasada zerowa, w pierwszej próbce, wykorzystując już istniejące narzędzie,unique_ptr, pokazuje jako miły skrót do zarządzania uchwytami. Dodatkowe założenia, których wymaga, sprawiają, że nie spełnia oczekiwań. Właściwe założenia są takie, że maszuchwyt a ty maszfunkcja niszczenia zasobów niszczy zasób podany przezuchwyt. Czy uchwyt jestvoid *, aGLuint, cokolwiek, to nie powinno mieć znaczenia, a co gorsza, nie powinno się nawet wymagać od niego patrzeniaHANDLE typ wewnętrzny. W celu zarządzania sposobem RAII, jeśli idiom mówi, że jest do tego dobry i nie można go zastosować w takich sytuacjach, czuję, że nie jest to w tym przypadku dobre z danym narzędziem.

EDYCJA 3

Przykładem może być sytuacja, powiedzmy, że jesteś odpowiedzialny za korzystanie ze świeżej biblioteki C innej firmy. Zawiera aFooHandle create_foo() i avoid destroy_foo(FooHandle). Więc myślisz, „użyjmy FooHandle, stosując regułę zero”. Ok, idziesz za pomocąunique_ptr, aunique_ptr do czego sam się pytasz? JestFooHandle wskaźnik ?, dzięki czemu używasz aunique_ptr doFooHandlejestnie naświetlony podstawowy typ? Czy to jestint?, abyś mógł używać go prosto, czy lepiej (re)typedef rzeczy takie jak @NicolBolas zrobiły w swojej odpowiedzi. Dla mnie wydaje się jasne, nawet w tak trywialnej sytuacjiunique_ptr już pokazuje, że nie jestideał nadaje się do zarządzania uchwytami zasobów.

Zrzeczenie się:

Próbowałem przeformułować i lepiej wyrazić siebie w:

Czy dostępna jest odpowiednia „własność w pakiecie” dla „uchwytów”?EDYCJA 4

Znalazłem to, czego szukałem, przedstawiłem to jako odpowiedź na przeformułowane pytanie:https://stackoverflow.com/a/14902921.