Список случаев, когда должен использоваться оператор USING

Question

«Файл и шрифт - это примеры управляемых типов, которые имеют доступ к неуправляемым ресурсам (в данном случае - к файлам и контекстам устройств). Существует много других неуправляемых ресурсов и типов библиотеки классов, которые инкапсулируют все такие типы должны реализовывать интерфейс IDisposable. Как правило, когда вы используете объект IDisposable, вы должны объявить его и создать его в операторе using. " - MSDN

Есть ли список таких случаев (управляемые типы, которые получают доступ к неуправляемым ресурсам, таким как FILE и FONT, ...), где должен использоваться оператор USING?

Answer 1

Всякий раз, когда у вас есть ресурс, который нуждается в детерминированной очистке, то есть вы хотите, чтобы у вас была возможность «уничтожить», как только вы закончите с этим.

Более подробно интерфейс IDisposible в основном пытается решить проблему отсутствия ключевого слова `` delete '' в языках .net. Поскольку CLR - сбор мусора, вы никогда не знаете, когда будет запущен финализатор (деструктор) для объекта. GC имеет право ждать до тех пор, пока вам нравится, прежде чем обойтись, чтобы освободить управляемый ресурс.

Однако многие управляемые ресурсы обертывают основные конечные ресурсы - память - это не единственное, что необходимо выделить и освободить. Как уже упоминалось, дескрипторы файлов - один; база данных обрабатывает другую - существует множество примеров. Чтобы избежать непоследовательного беспорядка идиом очистки, шаблон IDisposible используется, чтобы сказать «Пожалуйста, отпустите свои конечные ресурсы, я покончил с ними». Поскольку он встроен в структуру, он получает специальную поддержку языка через «использование», чтобы гарантировать, что вы никогда не забудете вызвать методы Dispose и, следовательно, «утечку» неуправляемого ресурса.

Это не означает, что все IDisposible исполнители должны быть обернуты в использовании - если вы сохранить ссылку, и нужно их в будущем, вы должны, конечно, не обернуть их, как вы бы вызвать преждевременное высвобождение основной ресурс. Вызовите Dispose только, когда вы закончите с объектом и, таким образом, оберните «использование», только если вы знаете, что с ним закончили после окончания использования области.

Как и следовало ожидать, языки, которые имеют детерминированное разрушение, такие как C++/CLI, не нуждаются в «использовании». Объекты C++/CLI без кучи имеют метод Dispose, который вызывается автоматически, когда они выпадают из области видимости, имитируя поведение деструктора, которое пытается попытаться создать шаблон.

Answer 2

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

Answer 3

Любой тип, который реализует IDisposable, должен использовать using.

Обновление (в ответ на комментарии): using должен окружать экземпляр IDisposable типа, предполагая, что это не требуется в большем объеме.

Answer 4

Правильный подход всегда использовать using заявления, когда тип реализует интерфейс IDisposable, но знают исключения из правила.

Известные исключения:

• Основная форма (Windows Forms приложение, поскольку он управляется Application класса)
• SystemPens.*, SystemBrushes.* (эти статические экземпляры кэшируются)
• Icons.* (эти статические экземпляры кэшируются внутренне)
• Registry.* (эти статические экземпляры являются кешем d внутренне)
• AutoResetEvent, ManualResetEvent (фактически должно быть утилизированы, но если вы делаете это сделать очень осторожно, так как это может привести к гоночным условиям)

Список известных исключений, конечно, не полный.

Answer 5

Простым правилом является «всякий раз, когда у вас есть ресурс, который должен быть освобожден сразу после использования, а не в какой-то неизвестный момент в будущем, когда сборщик мусора обходит его, чтобы освободить его».

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