Как я могу найти размер памяти ссылаемым указателем?

Не должно быть никаких дальнейших вызовов к методам объекта после того, как Располагают, был назван на нем (хотя объект должен терпеть дальнейшие вызовы для Расположения). Поэтому пример в вопросе глуп. Если Располагают, назван, то сам объект может быть отброшен. Таким образом, пользователь должен просто отбросить все ссылки на тот целый объект (установите их в NULL), и все связанные объекты, внутренние к нему, будут автоматически очищены.

Что касается общего вопроса об управляемом/неуправляемом и обсуждении в других ответах, я думаю, что любой ответ на этот вопрос должен запуститься с определения неуправляемого ресурса.

то, К чему это сводится, - то, что существует функция, которую можно вызвать для помещения системы в состояние, и существует другая функция, которую можно вызвать для возвращения его из того состояния. Теперь, в типичном примере, первый мог бы быть функцией, которая возвращает дескриптор файла, и второй мог бы быть вызовом к CloseHandle.

, Но - и это - ключ - они могли быть любой парой соответствия функций. Каждый создает состояние, другой разъединяет его. Если состояние было создано, но не разъединено уже, то экземпляр ресурса существует. Необходимо принять меры, чтобы разрушение произошло в нужное время - ресурсом не управляет CLR. Единственный автоматически тип управляемого ресурса является памятью. Существует два вида: GC и стек. Типами значения управляет стек (или путем подтягивания поездки в ссылочных типах), и ссылочными типами управляет GC.

Эти функции могут вызвать изменения состояния, которые могут быть свободно чередованы или, возможно, должны быть отлично вложены. Изменения состояния могут быть ориентированы на многопотоковое исполнение, или они не могли бы.

Взгляд на пример в вопросе Судьи. Изменения в добавлении отступа Файла журнала должны быть отлично вложены, или все это идет не так, как надо. Также они вряд ли будут ориентированы на многопотоковое исполнение.

возможно цеплять поездку со сборщиком "мусора" для очищения неуправляемых ресурсов. Но только если функции изменения состояния ориентированы на многопотоковое исполнение, и два состояния могут иметь время жизни то перекрытие всегда. Таким образом, пример Судьи ресурса не должен иметь финализатора! Это просто не помогло бы никому.

Для тех видов ресурсов, можно просто реализовать IDisposable без финализатора. Финализатор является абсолютно дополнительным - это должно быть. Это приукрашено или даже не упомянуто во многих книгах.

затем необходимо использовать using оператор, чтобы иметь любой шанс обеспечения, которое Dispose называют. Это по существу похоже на подтягивание поездки со стеком (поэтому, как финализатор к GC, using к стеку).

недостающая часть - то, что необходимо вручную записать, Располагают и заставляют его звонить на поля и базовый класс. C++ / программисты CLI не должен делать этого. Компилятор пишет это для них в большинстве случаев.

существует альтернатива, которая я предпочитаю для состояний, чтобы вложенное множество отлично и не было ориентировано на многопотоковое исполнение (кроме чего-либо еще, избегая, чтобы IDisposable сэкономил Вас проблема наличия спора с кем-то, кто не может сопротивляться добавлению финализатора к каждому классу, который реализует IDisposable).

Вместо того, чтобы писать класс, Вы пишете функцию. Функция принимает, что делегат перезванивает к:

public static void Indented(this Log log, Action action)
{
    log.Indent();
    try
    {
        action();
    }
    finally
    {
        log.Outdent();
    }
}

И затем простой пример был бы:

Log.Write("Message at the top");
Log.Indented(() =>
{
    Log.Write("And this is indented");

    Log.Indented(() =>
    {
        Log.Write("This is even more indented");
    });
});
Log.Write("Back at the outermost level again");

лямбда, передаваемая в, служит блоком кода, таким образом, она похожа на Вас, делают Вашу собственную управляющую структуру для служения той же цели как using, за исключением того, что у Вас больше нет опасности вызывающей стороны, злоупотребляющей ею. Нет никакого способа, которым они могут не очистить ресурс.

Эта техника менее полезна, если ресурс является видом, который может иметь перекрывающееся время жизни, потому что затем Вы хотите смочь создать ресурс A, затем ресурс B, затем уничтожить ресурс A и затем позже уничтожить ресурс B. Вы не можете сделать этого при принуждении пользователя к отлично вложенному множеству как это. Но затем необходимо использовать IDisposable (но все еще без финализатора, если Вы не реализовали threadsafety, который не свободен).