Действительно ли очистка объекта/освобождение массива необходимы в VB6/VBA (Плюсы / Минусы?)
многое из того, что я узнал о VB, я узнал из использования статического анализа кода (в частности, анализатор проекта Aivosto). И одна из вещей, которую он проверяет, - это то, очистили ли вы все объекты и массивы. Я делал это вслепую, потому что так говорил папа. Но теперь, когда я знаю немного больше о том, как глаг освобождает ресурсы, мне кажется, что эти вещи должны происходить автоматически. Это унаследованная функция от pre VB6, или есть причина, по которой вы должны явно установить объекты обратно в ничто и использовать Erase на массивах?
5 ответов
проблема, как я понимаю, связана с тем, что VB6 (и его предшественники) имеет свои корни в COM и своей системе сбора мусора для подсчета ссылок.
представьте, например, что вы объявляете ссылку на объект из сторонней библиотеки. Этот объект имеет счетчик ссылок COM, который используется как для поддержания его жизни, так и для определения того, когда он должен быть уничтожен. Он не уничтожается, когда вы устанавливаете его в ничто, но когда счетчик ссылок объекта достигает нуль.
теперь не все com-компоненты были написаны на Visual Basic. Некоторые были написаны на C или C++. Структурированная обработка исключений существовала не на всех языках. Таким образом, если произошла ошибка, количество ссылок на объект не было гарантировано должным образом уменьшено, и COM-объекты, как известно, зависали дольше, чем они были предназначены. Это не было проблемой с Visual Basic, как таковой. Это была проблема со связью. (И это, вы можете заметить, почему .NET не использует ссылку подсчет.)
вот почему разработчики Visual Basic стали одержимы освобождением ссылок на объекты до выхода из подпрограмм. Вы просто не знаете, какой компонент вы выделяете, создавая под капотом. Но когда вы выпускаете ссылку на него, вы, по крайней мере, выпускаете свой счетчик ссылок на него. Это стало почти религиозной мантрой. Объявлять, использовать, выпускать. Это был способ делать вещи.
конечно, Visual Basic может быть лучше или быстрее при разыменовании переменные, объявленные в стеке. Но, черт возьми, я хочу, чтобы было очевидно, что эти предметы были выпущены. Небольшая уверенность проходит долгий путь, когда вы пытаетесь отследить утечку памяти.
Мэтт Керланд, автор Расширенный Visual Basic 6, кто знает о Visual Basic больше, чем большинство из нас когда-либо будет, думает, что это напрасные усилия. Рассмотрим эту цитату (p110) о DAO, библиотеке доступа к данным COM, которая в первую очередь нацелена на компонент Access Database Engine:
еще один пример плохого кода демонтажа. DAO имеет близкие методы, которые должны быть назвать в правильном порядке, и объекты должны быть освобождены в правильный порядок также (Recordset перед базой данных, например). Этот поведение одной плохой объектной модели имеет привело к заблуждению, что VB утечки память, если вы явно не задали все локальные переменные в nothing на конец функции. Это совершенно ложное представление в хорошо продуманная объектная модель. Глаг можете очистите переменные быстрее в конце Sub line чем вы можете от кода, и он проверяет переменные, даже если вы явно отпустите свои ссылки. Любые попытки сделать это дублированный.
вы читали этот Aivosto веб-страницы (от создателей Project Analyzer)?
Если вы используете статические переменные, важно восстановить память они заняты, когда тебе не нужно ... переменных больше нет. С динамическим память переменных-это не столько проблема, потому что они разрушены когда процедура закончится.
другими словами, вам не нужно беспокоиться об очистке обычных, нестатических, локальных переменная.
Я всегда делаю это для хорошей практики, вы никогда не знаете, что может сделать исключение, если вы попадаете в один, и ваши объекты не освобождаются. Вы должны передать их в операторах finally и убедиться, что они не используют память, иначе вы можете столкнуться с утечкой памяти.
У меня была проблема внутри простой системы отслеживания времени, где сервер продолжал сбой случайным образом, потребовались недели, чтобы определить, что это утечка памяти объекта, который должен был самоуничтожиться на его собственный. Мой код был брошен в исключение и никогда не очищался после себя, заставляя сервер (фактический веб-сайт не весь сервер) идти вниз.
да, установите все объекты в ничто и очистите столько, сколько сможете. VB6 печально известен тем, что имеет утечки памяти, когда не очищает ваши вещи. Сбор мусора был суб-паритет в VB6 / VBA.