Как сделать деструкторы стиля C++ в C#?

~ClassName()
{
}

РЕДАКТИРОВАТЬ (жирный шрифт):

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

«Принятый» шаблон удаления в соответствии с рекомендациями по платформе выглядит следующим образом с неуправляемыми ресурсами:

    public class DisposableFinalisableClass : IDisposable
    {
        ~DisposableFinalisableClass()
        {
            Dispose(false);
        }

        public void Dispose()
        {
            Dispose(true);
        }

        protected virtual void Dispose(bool disposing)
        {
            if (disposing)
            {
                // tidy managed resources
            }

            // tidy unmanaged resources
        }
    }

Таким образом, приведенное выше означает, что если кто-то вызывает Dispose, неуправляемые ресурсы приводятся в порядок. Однако в случае, если кто-то забыл вызвать Dispose или исключение, препятствующее вызову Dispose, неуправляемые ресурсы все равно будут убраны, только немного позже, когда GC получит на нем свои грязные перчатки (включая закрытие приложения или неожиданное завершение ).

К сожалению, это невозможно сделать прямо в коде. Если это проблема внутри компании, существуют различные решения для анализа кода, которые могут выявить подобные проблемы. Вы смотрели на FxCop? Я думаю, что это отловит эти ситуации и во всех случаях, когда объекты IDisposable могут остаться висящими. Если это компонент, который люди используют за пределами вашей организации, и вам не может потребоваться FxCop, тогда документация - ваш единственный выход :).

Обновлено: в случае финализаторов это на самом деле не гарантирует, когда произойдет финализация. Так что это может быть решением для вас, но это зависит от ситуации.

Это ничем не отличается от того, что программист забывает использовать Удалить в C++, за исключением того, что, по крайней мере, здесь сборщик мусора все равно его догонит.

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

@Quarrelsome

If will get called when the object is moved out of scope and is tidied by the garbage collector.

Это утверждение вводит в заблуждение, и как я его прочитал, неверно: нет абсолютно никакой гарантии, когда будет вызван финализатор. Вы абсолютно правы, что в billpg должен быть реализован финализатор; однако он не будет вызываться автоматически, когда объект выходит из области видимости, как он того хочет. Свидетельство, первый пункт под Операции завершения имеют следующие ограничения.

Фактически Microsoft предоставила Крису Селлсу грант на создание реализации .NET, которая использовала бы подсчет ссылок вместо сборки мусора Связь. Как оказалось, был удар по производительности значительный.

Лучше всего заставить этот класс самостоятельно высвобождать дорогостоящий ресурс, прежде чем он будет удален.

Например, если это соединение с базой данных, подключайтесь только при необходимости и немедленно выпускайте, задолго до того, как фактический класс будет удален.

Где я работаю, мы руководствуемся следующими принципами:

• Каждый класс IDisposable должен имеет финализатор
• Всякий раз, когда используется объект IDisposable, он должен использоваться внутри блока using. Единственное исключение - если объект является членом другого класса, и в этом случае содержащий класс должен быть IDisposable и должен вызывать метод элемента Dispose в своей собственной реализации Dispose. Это означает, что разработчик никогда не должен вызывать Dispose, кроме как внутри другого метода Dispose, что устраняет ошибку, описанную в вопросе.
• Код в каждом финализаторе должен начинаться с журнала предупреждений / ошибок, уведомляющего нас о том, что финализатор был вызван. Таким образом, у вас есть очень хорошие шансы обнаружить такие ошибки, как описано выше, перед выпуском кода, а также это может быть намеком на ошибки, возникающие в вашей системе.

Чтобы облегчить нашу жизнь, у нас также есть метод SafeDispose в нашей инфраструктуре, который на всякий случай вызывает метод Dispose своего аргумента в блоке try-catch (с ведением журнала ошибок) (хотя методы Dispose не должны вызывать исключения. ).

См. Также: предложения Крис Лайон относительно IDisposable

Редактировать: @Quarrelsome: Вам следует вызвать GC.SuppressFinalize внутри 'Dispose', чтобы, если объект был удален, он не был "повторно удален".

Также обычно рекомендуется держать флаг, указывающий, был ли объект уже удален или нет. Обычно бывает неплохо выглядит следующий паттерн:

class MyDisposable: IDisposable {
    public void Dispose() {
        lock(this) {
            if (disposed) {
                return;
            }

            disposed = true;
        }

        GC.SuppressFinalize(this);

        // Do actual disposing here ...
    }

    private bool disposed = false;
}

Конечно, блокировка не всегда необходима, но если вы не уверены, будет ли ваш класс использоваться в многопоточной среде или нет, рекомендуется сохранить ее.

Лучше всего использовать финализатор в вашем классе и всегда использовать блоки using.

На самом деле нет прямого эквивалента, финализаторы выглядят как деструкторы C, но ведут себя по-другому.

Вы должны вкладывать блоки using, поэтому по умолчанию макет кода C# помещает их в одну строку ...

using (SqlConnection con = new SqlConnection("DB con str") )
using (SqlCommand com = new SqlCommand( con, "sql query") )
{
    //now code is indented one level
    //technically we're nested twice
}

Когда вы не используете using, вы все равно можете делать то, что он делает под капотом:

PleaseDisposeMe a;
try
{
    a = new PleaseDisposeMe();
    throw new Exception();
}
catch (Exception ex) { Log(ex); }  
finally {    
    //this always executes, even with the exception
    a.Dispose(); 
}

С управляемым кодом C# очень хорошо заботится о своей собственной памяти, даже когда что-то плохо расположено. Если вы часто имеете дело с неуправляемыми ресурсами, это не так уж и важно.