Динамический массив delphi освобождение памяти
Репутация: 6
Всего: 23
Есть у меня несколько массивов string'ов, нужно их почистить. Понятно, что можно циклом просто обнулить значения. А есть ли в Delphi функции для очистки массивов? В Си, кажись, memset и др. (так просто не вспомню).
Репутация: 1
Всего: 5
Как бы ты не старался быть хорошим и правильным человеком с принципами и уважительным отношением к другим, всегда найдется кто-то, кто бросит в тебя какашку
Репутация: 1
Всего: 5
Да, самое важное. Если, например, s:string; то выполнение s:=''; не приводит к освобождению занимаемой памяти!
Как бы ты не старался быть хорошим и правильным человеком с принципами и уважительным отношением к другим, всегда найдется кто-то, кто бросит в тебя какашку
Репутация: 6
Всего: 23
remax, массив не динамический (и не должен быть. ).
Цитата |
Да, самое важное. Если, например, s:string; то выполнение s:=''; не приводит к освобождению занимаемой памяти! |
Вот так я и не хочу делать в цикле. У меня массивы строк.
Репутация: 1
Всего: 5
Цитата(NiJazz @ 6.2.2004, 10:24) |
массив не динамический (и не должен быть. ). |
Цитата |
var ar:array of string; s:string; begin setlength(ar,100); // Заказали 100 элементов (0..99) ar[25]:='12fkjfsjfjfjsd';// Присвоили 26 элементу s:=ar[25]; setlength(ar,0); // Освободили занимаемую память end; |
Что здесь плохого?
Как бы ты не старался быть хорошим и правильным человеком с принципами и уважительным отношением к другим, всегда найдется кто-то, кто бросит в тебя какашку
Репутация: 6
Всего: 23
Цитата |
Почему? |
Работа идёт с типизированными файлами, а там динамические массивы использовать нельзя.
Репутация: нет
Всего: 1
Цитата |
выполнение s:=''; не приводит к освобождению занимаемой памяти |
Репутация: 6
Всего: 23
Paradox, скорее так и есть. Это ж есть массив char-ов, след-но если
Код |
var s: string[255] ss: integer; begin s := ''; ss := sizeof(s); end; |
то ss выдаст 255 байт.
Поэтому присваивание пустого значения память не освобождает.
Но мне нужно почистить не для освобождения памяти.
Репутация: 6
Всего: 23
Репутация: 1
Всего: -11
Репутация: нет
Всего: 1
Код |
s: string[255] |
если у тебя
Код |
arr:array[1..n] of string; |
Код |
arr[i]:=''; |
Но так как у тебя работа с фалами то вроятно
Код |
arr:array[1..n] of string; |
Цитата |
Но мне нужно почистить не для освобождения памяти. |
Репутация: 6
Всего: 137
Цитата(NiJazz @ 6.2.2004, 15:12) |
Работа идёт с типизированными файлами, а там динамические массивы использовать нельзя. |
Поясни
Репутация: 6
Всего: 23
Цитата |
а что значит почистить в твоем случае ? |
Просто анулировать значения, чтобы глюков не было.
dm9
Цитата |
Поясни |
У меня есть
Код |
type MyRecord = record . StrArr:= array[1..10] of string[50]; . end; var f: file of MyRecord; |
Тут должны быть стабильные размеры строк и массивов. Если размерность не задавать, а просто array of string, то будет ошибка.
Репутация: нет
Всего: 1
Репутация: 6
Всего: 23
Запрещается!
1. Публиковать ссылки на вскрытые компоненты
2. Обсуждать взлом компонентов и делиться вскрытыми компонентами
Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, Snowy, MetalFan, bems, Poseidon, Rrader.
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | Delphi: Общие вопросы | Следующая тема » |
[ Время генерации скрипта: 0.1431 ] [ Использовано запросов: 21 ] [ GZIP включён ]
Чтобы освободить память мне достаточно ввести SetLength(a, 0) или надо сначала пройтись по массиву и освободить в него вложенные?
TList и освобождение памяти
Имеет var iItems:TList procedure AddRecord (Value: TStringList); var s:TStringList; begin.
Освобождение памяти при выходе из программы
Просматривая исходные тексты программ, заметил, что часто на событие FormDestroy вешают удаление.
Освобождение памяти после репликации
Всем привет. Версия Delphi XE6, база данных FireBird. В своей программе реализовал механизм.
Освобождение памяти после закрытие данных в Делфи
Мир всем и привет ! как освободит, очищать память приложение после FDQuery.close; ?
Все динамические массивы уничтожаются сами по окончании программы. Если массив очень большой и Вам это надо, можете написать a:=nil;
Все динамические массивы уничтожаются сами по окончании программы. Если массив очень большой и Вам это надо, можете написать a:=nil;
Можно прочитать статью: Блог GunSmoker-а: Ищем утечки памяти - и проверить самому.
Подключите FastMM, настройте информирование, проверьте оба варианта освобождения.
Можно прочитать статью: Блог GunSmoker-а: Ищем утечки памяти - и проверить самому.
Подключите FastMM, настройте информирование, проверьте оба варианта освобождения.
хороший тон - ВСЕГДА освобождать то что ты сам выделял
несмотря на то, что по умолчанию компилятор добавит скрытый код
зато это сильно поможет впоследствии в разборе старого кода другим людям или даже самому себе
хороший тон - ВСЕГДА освобождать то что ты сам выделял
несмотря на то, что по умолчанию компилятор добавит скрытый код
зато это сильно поможет впоследствии в разборе старого кода другим людям или даже самому себе
Ну да, я поэтому и спросил. Но цель вопроса - понять нужно ли вложенные массивы удалять по отдельности или достаточно верхний обнулить
Конечно знает. Справка по вашей версии компилятора знает как оно обрабатывается в вашей версии компилятора.
Только вдруг у вас Делфи5 какая-нибудь? Я с пятой не работал, вполне допускаю, что там может оказаться не так как в текущей. Проще и быстрее проверить.
А ещё проще и эффективнее - последовать совету krapotkin'а.
Конечно знает. Справка по вашей версии компилятора знает как оно обрабатывается в вашей версии компилятора.
Только вдруг у вас Делфи5 какая-нибудь? Я с пятой не работал, вполне допускаю, что там может оказаться не так как в текущей. Проще и быстрее проверить.
А ещё проще и эффективнее - последовать совету krapotkin'а.
А по совету - ну так я и спросил для того чтобы правильно освободить память
@Fil а зачем ты переместил тему в дельфи для начинающих, если никто из про не смог ответить полностью на вопрос до сих пор?
Добавлено через 2 минуты
я и дальше вброшу - судя по ру и англо-форумам при обнулении динамического массива (рекорда точнее), память не освобождается, а резервируется и используется потом вторично
@Fil а зачем ты переместил тему в дельфи для начинающих, если никто из про не смог ответить полностью на вопрос до сих пор?
Чтобы освободить память мне достаточно ввести SetLength(a, 0) или надо сначала пройтись по массиву и освободить в него вложенные?
то достаточно ввести SetLength(a,0). Насколько я знаю все, что было создано не программистом (а SetLength - это как раз такая ситуация) не программистом же и должно быть удалено. А вот если используется New, то там без Dispose не обойтись. Сколько я имел дел с динамическими массивами и использовал SetLength столько раз я не получал утечек памяти по завершении программы (а я во время отладки всегда использую ReportMemoryLeaksOnShutdown).
я и дальше вброшу - судя по ру и англо-форумам при обнулении динамического массива (рекорда точнее), память не освобождается, а резервируется и используется потом вторично
Как это относится к освобождению памяти как таковой? Если это поведение стандартное для Делфи, то, имхо, туда и не стоит лезть, потому что в 99% случаев это будет корректное поведение, а оставшийся 1% случаев - это, обычно, слишком явные косяки, типа попытки закачки гигабайтного массива в память.
то достаточно ввести SetLength(a,0). Насколько я знаю все, что было создано не программистом (а SetLength - это как раз такая ситуация) не программистом же и должно быть удалено. А вот если используется New, то там без Dispose не обойтись. Сколько я имел дел с динамическими массивами и использовал SetLength столько раз я не получал утечек памяти по завершении программы (а я во время отладки всегда использую ReportMemoryLeaksOnShutdown).
Как это относится к освобождению памяти как таковой? Если это поведение стандартное для Делфи, то, имхо, туда и не стоит лезть, потому что в 99% случаев это будет корректное поведение, а оставшийся 1% случаев - это, обычно, слишком явные косяки, типа попытки закачки гигабайтного массива в память.
ну во первых, четкого ответа не было, только предположения или философствование
по памяти - у меня прога на серваке работает 24/7 соответственно если правильно не освобождать память, то рано или поздно она повиснет.
когда мне нужно им воспользоваться, я выгружаю его, с этим проблем нет:
Теперь сам вопрос: каждый раз, перед тем, как выгрузить мой массив, я его освобождаю память (ну, или мне кажется, что освобождаю)
Как освобождать память при большом количестве записей в TQuery?
Доброе время суток, Вопрос такой, как освобождать память при большом колличестве записей(999.
Dll на C++ кушает память, как правильно удалять и освобождать память?
Добрый день, совсем мало опыта в программировании на C++, помогите пожалуйста знатоки С++. Есть.
Как правильно освобождать память
Подскажите пожалуйста ,где память чистить в таком случае?Или как это правильно сделать. char.
Как правильно освобождать память от вектора?
ПОжалуйста если можно пример для одномерного и двумерного. циклом или метод есть какой то?
Решение
Правильно ли понял?
Имеет ли какое-то значение, что размещаю объекты списка на объектах другого списка, и достаточно ли этого для очистки памяти на моб приложениях. Или еще необходим какой-то дополнительный комплекс мер?
FIL, ага, сейчас глянул видос, достаточно быстро. По производительности и загрузке системы, наверное, тоже более правильно, чем создавать списки.
Правда, если, скажем, я захочу запихнуть "маленький" tchart на один из итемов, то . так вообще нормально делать?
Вопрос предыдущего поста в силе.
я не очень понимаю логику, так что воздержусь одобрять
listBox - это в основном для небольшого количества статических элементов
для остальных я создаю listView
у меня есть внутренние списки некоторой модели данных TObjectList
по этой модели я в любой момент пересоздаю ListView, кладя нужные кнопки и текст куда мне надо, и забывая о них навсегда.
и незачем держать списки визуальных объектов, если есть список моих данных
Добавлено через 56 секунд
TChart сам по себе тяжелый, зачем его туда кидать
лучше самому отрисовать, 100% картинка небольшая должна быть
Репутация: нет
Всего: нет
Репутация: нет
Всего: 41
Help Delphi утверждает, что для освобожение памяти динамическаго массива, нужно переменным присвоить nil или передать как параметр Finalize.
Репутация: нет
Всего: нет
Кстати. Примерно такой же вопрос у меня и по интерфейсам. Они имеют тоже свойство что и динамические массивы - для освобождения ресурсов связанных с интерфейсом, нужно всем ссылкам на этот интерфейс присвоить значение nil.
- Если у меня в классе есть поле - ссылка на интерфейс, надо ли мне в деструкторе присваивать nil этому полю?
- А если у меня в классе есть поле массив ссылок на интерфейсы?
- А если этот массив динамический? :-)
Репутация: нет
Всего: 41
Цитата |
Примерно такой же вопрос у меня и по интерфейсам. Они имеют тоже свойство что и динамические массивы - для освобождения ресурсов связанных с интерфейсом, нужно всем ссылкам на этот интерфейс присвоить значение nil. |
Кто это вам такое сказал?
Переменная, имеющая тип interface - это всего лишь УКАЗАТЕЛЬ на таблицу методов какого-то объекта. Никаких дополнительных ресурсов эта переменная не занимает.
Читайте мою статью о COM, я там это вроде достаточно наглядно показываю.
Репутация: 48
Всего: 207
Динамические массивы можно легко удалить из памяти установив их длину в ноль функцией SetLength. Интерфейсы не нуждаются в освобождении памяти - это только указатель, реально никаких структур в приложении не создается. По поводу установки массива в Nil - берут меня сомнения, как бы при этом не заставить просто массив показывать в никуда, а сами данные массива могу остаться в памяти - я неуверен может кто-то знает лучше?
Репутация: нет
Всего: нет
Цитата |
Интерфейсы не нуждаются в освобождении памяти - это только указатель, реально никаких структур в приложении не создается |
Это утверждение не верно.
Цитата |
Переменная, имеющая тип interface - это всего лишь УКАЗАТЕЛЬ на таблицу методов какого-то объекта. Никаких дополнительных ресурсов эта переменная не занимает. |
Тут сформулировано точнее, но опять-таки не совсем правильное утверждение. Ниже я постараюсь объяснить почему.
Цитата |
По поводу установки массива в Nil - берут меня сомнения, как бы при этом не заставить просто массив показывать в никуда, а сами данные массива могу остаться в памяти - я неуверен может кто-то знает лучше? |
Память освобождается - это совершенно точно. Поскольку написано в help`е(на что указал Fantasist). Да и проверил я это полазив по исходникам и окушку CPU (help тоже бывает врет). А вот установка размера равного в 0, хотя и делает тоже самое(я ей до последнего времени тоже пользовался), но в help`е не упомянута.
Цитата |
Кто это вам такое сказал? |
Чарльз Калверт. стр 359 его книги Delphi4 Энциклопедия пользователя.
глава "разрушение интерфейсов".
Цитаты:
Цитата |
Интерфейс не должен разрушаться, поскольку Delphi делает это автоматически. . skip. Все это хорошо и прекрасно, но что делать если требуется явно уничтожить объект? . skip. Коректный способ разрушения этих объектов заключается в том, чтобы установить их равными nil: MyInterface := nil; |
Далее я своими словами.
Дело в том, что хотя интерфейсы это просто указатели, но они указатели на объекты. Если покопаться то там выясняется что это не просто указатели. Важно что когда мы создаем интерфейс, то мы связываем его с неким объектом (который создается явно или нет, при этом забирая-таки ресурсы) и при присваивании интерфейсу значения nil этот объект автоматически разрушается (если на него нет других ссылок). Тоже происходит и при выходе объекта их области видимости. Примерно также ведет себя и динамический массив. И интерфейс и динамический массив, это "умные указатели", кроме самого адреса, на который они указывают, они содержат еще и информацию о количестве ссылок которые ссылаються на этот участок памяти. Когда число это ссылок становиться = 0 объект, на который они ссылаються, разрушается.
Точно также ведет себя тип string.
Проблема тут только одна - как определяется выход из области видимости. Когда есть процедура и в ней локально определен такой "умный указатель", то все просто - вышли из процедуры, указатель обнулился автоматически. А если есть глобальные классы, которые разрушаються и создаються когда угодно и содержат указатели друг на друга то тут начинается путаница. Надо будет мне поразбираться с этим как-нибудь повнимательнее.
Репутация: 48
Всего: 207
Репутация: 48
Всего: 207
Репутация: нет
Всего: 41
Цитата |
Это утверждение не верно. |
Вы бы прежде чем так утверждать, ознакомились бы с вопросом. К сожалению, почерпнутая Вами из какой-то книги цитата не объясняет Вам многого, а возможно запутывает. Все что сказанно Вами после слов "Далее моими словами. " не корректно, а то и просто ошибочно.
Представте себе, что вы написалт COM объект на Delphi, а потом кто-то пытается использовать его в другом языке программирования. Следуя стандарту, он получит указатель на интерфейс и будет с ним работать как с указателем! Подчиняясь правилам пользования интерфейсом. А то и просто загляните в TObject.GetInterface, слава богу, исходники есть. Там возвращается просто указатель полученный из таблицы интерфейсов, и ничего более.
Далее. Термин "умные указатели" пришел не отсюда, и означает несколько иное. Обычно это класс, который конструирует динамический объект и удаляет его. Сам такой класс помещают в стеке, что позволяет избежать случайных потерь памяти, или потерю ее при исключениях. То, что происходит в Delphi при присвоении nil динамическому массиву, обычно называют механизмом сборки мусора - когда автоматически освобождается памяти из под неиспользуемых объектов без явного указания пользователя. Если такое поддерживается для интерфейсов, то это извращение и я никогда не советую это использовать - очень черевато конфликтами да и не красиво это.
Репутация: нет
Всего: нет
Так сказать оправдание
Sorry, я не точно (в очередной раз) выразился в результате вы не поняли, что я хотел сказать.
Я ни в коей мере не имел ввиду, что нужно вручную удалять объект на который ссылается интерфейс. Я хотел просто указать на то, что в случае когда этот объект уже в программе не нужен то имеет смысл освободить сам интерфейс, путем присваивания ему nil. При этом если ссылок на объект больше нет (не только в моей программе, а вообще во всех запущенных приложениях) то объект автоматически будет уничтожен. Действительно что-то типа "сборки мусора" ("умный указатель" в самом деле был упомянут мной не коректно). Только она отоситься не к отдельному приложению, а ко всей системе в целом.
Конечено можно и не присваивать интерфейсу этот самый nil, и тогда счеткик указателей на объект связанный с интерфейсом уменьшиться при выходе программы из области видимости переменной-интерфейса. Но если у нас переменная-интерфейс объявлена глобально, то это значит что счетчик уменьшиться при завершении работы программы. То есть, допустим нам временно нужен был эксплорер и мы получили к нему доступ через интерфейс, сделали пару операций и забыли про него. Опять-таки допустим, другие программы не используют этот объект. В этом случае эксплорер все равно будет висеть в памяти (никому не нужный), отнимая ресурсы, пока наша программа не завершиться.
Теперь я нигде не ошибаюсь?
Репутация: 48
Всего: 207
Пришли к консенсусу
Не уверен, что присвоение интерфейсу Nil приведет к выгрузке из памяти COM, даже если его никто не использует, к сожалению винды еще и кэшируют загрузку объектов и по моему опыту, часто используемые объекты не выгружаются , но учитывая что создания 2х объектов невозможно утечки памяти не предвидится.
Репутация: нет
Всего: 41
По стандарту COM, счетчик должен уменьшаться за счет вызова Release.
Я посмотрел, действительно Delphi вызывает Release за тебя, в случае если переменной интерфейсного типа присвоить nil или при ее уничтожении(я имею ввиду, если она(переменная) стековая. Динасические не проверял). Однако естественно, что если вы сохраните указатель на интерфейс НЕ в интерфейсной переменной, а в pointer например, то ничего такого не произойдет. В любом случае, как я уже сказал, мне такой путь не нравиться. Это, конечно, может быть удобно, однако если вы придете в проффесиональное общество - это могут не одобрить. Стандарт - он на то и есть стандарт.
Запрещается!
1. Публиковать ссылки на вскрытые компоненты
2. Обсуждать взлом компонентов и делиться вскрытыми компонентами
Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, Snowy, MetalFan, bems, Poseidon, Rrader.
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | Delphi: Общие вопросы | Следующая тема » |
[ Время генерации скрипта: 0.1493 ] [ Использовано запросов: 21 ] [ GZIP включён ]
Репутация: нет
Всего: нет
Репутация: нет
Всего: 41
Help Delphi утверждает, что для освобожение памяти динамическаго массива, нужно переменным присвоить nil или передать как параметр Finalize.
Репутация: нет
Всего: нет
Кстати. Примерно такой же вопрос у меня и по интерфейсам. Они имеют тоже свойство что и динамические массивы - для освобождения ресурсов связанных с интерфейсом, нужно всем ссылкам на этот интерфейс присвоить значение nil.
- Если у меня в классе есть поле - ссылка на интерфейс, надо ли мне в деструкторе присваивать nil этому полю?
- А если у меня в классе есть поле массив ссылок на интерфейсы?
- А если этот массив динамический? :-)
Репутация: нет
Всего: 41
Цитата |
Примерно такой же вопрос у меня и по интерфейсам. Они имеют тоже свойство что и динамические массивы - для освобождения ресурсов связанных с интерфейсом, нужно всем ссылкам на этот интерфейс присвоить значение nil. |
Кто это вам такое сказал?
Переменная, имеющая тип interface - это всего лишь УКАЗАТЕЛЬ на таблицу методов какого-то объекта. Никаких дополнительных ресурсов эта переменная не занимает.
Читайте мою статью о COM, я там это вроде достаточно наглядно показываю.
Репутация: 48
Всего: 207
Динамические массивы можно легко удалить из памяти установив их длину в ноль функцией SetLength. Интерфейсы не нуждаются в освобождении памяти - это только указатель, реально никаких структур в приложении не создается. По поводу установки массива в Nil - берут меня сомнения, как бы при этом не заставить просто массив показывать в никуда, а сами данные массива могу остаться в памяти - я неуверен может кто-то знает лучше?
Репутация: нет
Всего: нет
Цитата |
Интерфейсы не нуждаются в освобождении памяти - это только указатель, реально никаких структур в приложении не создается |
Это утверждение не верно.
Цитата |
Переменная, имеющая тип interface - это всего лишь УКАЗАТЕЛЬ на таблицу методов какого-то объекта. Никаких дополнительных ресурсов эта переменная не занимает. |
Тут сформулировано точнее, но опять-таки не совсем правильное утверждение. Ниже я постараюсь объяснить почему.
Цитата |
По поводу установки массива в Nil - берут меня сомнения, как бы при этом не заставить просто массив показывать в никуда, а сами данные массива могу остаться в памяти - я неуверен может кто-то знает лучше? |
Память освобождается - это совершенно точно. Поскольку написано в help`е(на что указал Fantasist). Да и проверил я это полазив по исходникам и окушку CPU (help тоже бывает врет). А вот установка размера равного в 0, хотя и делает тоже самое(я ей до последнего времени тоже пользовался), но в help`е не упомянута.
Цитата |
Кто это вам такое сказал? |
Чарльз Калверт. стр 359 его книги Delphi4 Энциклопедия пользователя.
глава "разрушение интерфейсов".
Цитаты:
Цитата |
Интерфейс не должен разрушаться, поскольку Delphi делает это автоматически. . skip. Все это хорошо и прекрасно, но что делать если требуется явно уничтожить объект? . skip. Коректный способ разрушения этих объектов заключается в том, чтобы установить их равными nil: MyInterface := nil; |
Далее я своими словами.
Дело в том, что хотя интерфейсы это просто указатели, но они указатели на объекты. Если покопаться то там выясняется что это не просто указатели. Важно что когда мы создаем интерфейс, то мы связываем его с неким объектом (который создается явно или нет, при этом забирая-таки ресурсы) и при присваивании интерфейсу значения nil этот объект автоматически разрушается (если на него нет других ссылок). Тоже происходит и при выходе объекта их области видимости. Примерно также ведет себя и динамический массив. И интерфейс и динамический массив, это "умные указатели", кроме самого адреса, на который они указывают, они содержат еще и информацию о количестве ссылок которые ссылаються на этот участок памяти. Когда число это ссылок становиться = 0 объект, на который они ссылаються, разрушается.
Точно также ведет себя тип string.
Проблема тут только одна - как определяется выход из области видимости. Когда есть процедура и в ней локально определен такой "умный указатель", то все просто - вышли из процедуры, указатель обнулился автоматически. А если есть глобальные классы, которые разрушаються и создаються когда угодно и содержат указатели друг на друга то тут начинается путаница. Надо будет мне поразбираться с этим как-нибудь повнимательнее.
Репутация: 48
Всего: 207
Репутация: 48
Всего: 207
Репутация: нет
Всего: 41
Цитата |
Это утверждение не верно. |
Вы бы прежде чем так утверждать, ознакомились бы с вопросом. К сожалению, почерпнутая Вами из какой-то книги цитата не объясняет Вам многого, а возможно запутывает. Все что сказанно Вами после слов "Далее моими словами. " не корректно, а то и просто ошибочно.
Представте себе, что вы написалт COM объект на Delphi, а потом кто-то пытается использовать его в другом языке программирования. Следуя стандарту, он получит указатель на интерфейс и будет с ним работать как с указателем! Подчиняясь правилам пользования интерфейсом. А то и просто загляните в TObject.GetInterface, слава богу, исходники есть. Там возвращается просто указатель полученный из таблицы интерфейсов, и ничего более.
Далее. Термин "умные указатели" пришел не отсюда, и означает несколько иное. Обычно это класс, который конструирует динамический объект и удаляет его. Сам такой класс помещают в стеке, что позволяет избежать случайных потерь памяти, или потерю ее при исключениях. То, что происходит в Delphi при присвоении nil динамическому массиву, обычно называют механизмом сборки мусора - когда автоматически освобождается памяти из под неиспользуемых объектов без явного указания пользователя. Если такое поддерживается для интерфейсов, то это извращение и я никогда не советую это использовать - очень черевато конфликтами да и не красиво это.
Репутация: нет
Всего: нет
Так сказать оправдание
Sorry, я не точно (в очередной раз) выразился в результате вы не поняли, что я хотел сказать.
Я ни в коей мере не имел ввиду, что нужно вручную удалять объект на который ссылается интерфейс. Я хотел просто указать на то, что в случае когда этот объект уже в программе не нужен то имеет смысл освободить сам интерфейс, путем присваивания ему nil. При этом если ссылок на объект больше нет (не только в моей программе, а вообще во всех запущенных приложениях) то объект автоматически будет уничтожен. Действительно что-то типа "сборки мусора" ("умный указатель" в самом деле был упомянут мной не коректно). Только она отоситься не к отдельному приложению, а ко всей системе в целом.
Конечено можно и не присваивать интерфейсу этот самый nil, и тогда счеткик указателей на объект связанный с интерфейсом уменьшиться при выходе программы из области видимости переменной-интерфейса. Но если у нас переменная-интерфейс объявлена глобально, то это значит что счетчик уменьшиться при завершении работы программы. То есть, допустим нам временно нужен был эксплорер и мы получили к нему доступ через интерфейс, сделали пару операций и забыли про него. Опять-таки допустим, другие программы не используют этот объект. В этом случае эксплорер все равно будет висеть в памяти (никому не нужный), отнимая ресурсы, пока наша программа не завершиться.
Теперь я нигде не ошибаюсь?
Репутация: 48
Всего: 207
Пришли к консенсусу
Не уверен, что присвоение интерфейсу Nil приведет к выгрузке из памяти COM, даже если его никто не использует, к сожалению винды еще и кэшируют загрузку объектов и по моему опыту, часто используемые объекты не выгружаются , но учитывая что создания 2х объектов невозможно утечки памяти не предвидится.
Репутация: нет
Всего: 41
По стандарту COM, счетчик должен уменьшаться за счет вызова Release.
Я посмотрел, действительно Delphi вызывает Release за тебя, в случае если переменной интерфейсного типа присвоить nil или при ее уничтожении(я имею ввиду, если она(переменная) стековая. Динасические не проверял). Однако естественно, что если вы сохраните указатель на интерфейс НЕ в интерфейсной переменной, а в pointer например, то ничего такого не произойдет. В любом случае, как я уже сказал, мне такой путь не нравиться. Это, конечно, может быть удобно, однако если вы придете в проффесиональное общество - это могут не одобрить. Стандарт - он на то и есть стандарт.
Запрещается!
1. Публиковать ссылки на вскрытые компоненты
2. Обсуждать взлом компонентов и делиться вскрытыми компонентами
Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, Snowy, MetalFan, bems, Poseidon, Rrader.
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | Delphi: Общие вопросы | Следующая тема » |
[ Время генерации скрипта: 0.1355 ] [ Использовано запросов: 21 ] [ GZIP включён ]
Читайте также: