C # — Очистка до прекращения?

Этот вопрос меня давно беспокоит: я читал в MSDN DirectX статья следующие:

Деструктор (из приложения) должен выпустить любой (Direct2D) интерфейсы сохранены …

DemoApp::~DemoApp()
{
SafeRelease(&m_pDirect2dFactory);
SafeRelease(&m_pRenderTarget);
SafeRelease(&m_pLightSlateGrayBrush);
SafeRelease(&m_pCornflowerBlueBrush);
}

Теперь, если все данные приложения освобождаются / освобождаются при завершении (источник) почему я должен был пройти через задачу, чтобы сделать функцию для того, чтобы / и выпустить их по отдельности? это не имеет никакого смысла!

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

Ну, так как до сих пор я на самом деле не задавал свои вопросы, вот они:

  • Нужно ли что-то выпустить до прекращения? (объясните почему, пожалуйста)
  • Почему автор в MSDN-убежище решил сделать это?
  • Отличается ли ответ от родного & управляемый код? И.Е. Нужно ли мне убедиться, что все находится в конце программы, пока я пишу программу на C #? (Я не знаю о Java, но если бы там существовала утилизация, я уверен, что другие участники тоже бы за это ответили).

Спасибо!

5

Решение

Вам не нужно беспокоиться об управляемом контенте, когда ваше приложение закрывается. Когда память всего процесса разрушена, все это идет с этим.

Важны неуправляемые ресурсы.

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

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

Если у вас открыты сетевые подключения, вы захотите закрыть их. Если вы этого не сделаете, то ОС, скорее всего, не сделает это за вас (по крайней мере, на некоторое время; в конце концов она может заметить бездействие), и это довольно грубо для того, кто находится на другом конце. Они могут продолжать прислушиваться к ответу или продолжать присылать вам информацию, не зная, что вас там больше нет.

3

Другие решения

Теперь, если все данные приложения освобождаются / освобождаются
в конце (источник), почему я должен пройти через труд, чтобы сделать
функция для того, чтобы / и выпустить их по отдельности?

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

Я думаю, что есть более важная, более фундаментальная причина. Не убирать за собой — просто ленивое, неаккуратное программирование. Если вы ленивый и неаккуратный в уборке по окончании, вы ленивый и неряшливый в другое время? Если ваша склонность быть ленивой и неряшливой и перекрывать эту склонность только в тех областях, где вы осведомлены о потенциальных проблемах, то ваша склонность должна быть ленивой и небрежной. Что если есть потенциальные проблемы, о которых вы не знаете? Как вы можете полагаться на свою общую философию ленивого, небрежного программирования при написании правильных, надежных программ?

Не будь тем парнем. Убери за собой.

3

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector