Хочу garbage collector ;-)
Модератор: Модераторы
Хочу garbage collector ;-)
Я вот давно думаю...
Строковая переменная хранит счетчик ссылок. Как только он обнуляется, строка уничтожается. То же самое вроде с записями происходит. Потомки класса Exception тоже автоматически уничтожаются...
Может, уже пора сделать garbage collector как в java и не мучаться с утечками памяти? Никто не в курсе, как с этим дела обстоят?
Строковая переменная хранит счетчик ссылок. Как только он обнуляется, строка уничтожается. То же самое вроде с записями происходит. Потомки класса Exception тоже автоматически уничтожаются...
Может, уже пора сделать garbage collector как в java и не мучаться с утечками памяти? Никто не в курсе, как с этим дела обстоят?
- Иван Шихалев
- энтузиаст
- Сообщения: 1138
- Зарегистрирован: 15.05.2006 11:26:13
- Откуда: Екатеринбург
- Контактная информация:
Пользуйтесь интерфейсами и будет вам счастье.
// С записями ничего не происходит. Автоуправляются строки и динамические массивы.
// С записями ничего не происходит. Автоуправляются строки и динамические массивы.
Иван Шихалев писал(а):Пользуйтесь интерфейсами и будет вам счастье.
А данные где хранить? В записях и массивах, отдельно?
- Sergei I. Gorelkin
- энтузиаст
- Сообщения: 1409
- Зарегистрирован: 24.07.2005 14:40:41
- Откуда: Зеленоград
Как только проект с интерфейсами усложняется настолько, что в нем появляются циклические ссылки, все счастье сразу куда-то девается 
Изобретя недавно квадратноколесный велосипед с модулем DOM, я подумываю о том, чтобы портировать libgc (http://www.hpl.hp.com/personal/Hans_Boehm/gc/). Хотя, в общем-то, его можно и не портировать, а использовать просто так, в виде отдельной dll.
Изобретя недавно квадратноколесный велосипед с модулем DOM, я подумываю о том, чтобы портировать libgc (http://www.hpl.hp.com/personal/Hans_Boehm/gc/). Хотя, в общем-то, его можно и не портировать, а использовать просто так, в виде отдельной dll.
- Иван Шихалев
- энтузиаст
- Сообщения: 1138
- Зарегистрирован: 15.05.2006 11:26:13
- Откуда: Екатеринбург
- Контактная информация:
Climber писал(а):А данные где хранить? В записях и массивах, отдельно?
Зачем отдельно? В объектах и хранить.
Sergei I. Gorelkin писал(а):Как только проект с интерфейсами усложняется настолько, что в нем появляются циклические ссылки, все счастье сразу куда-то девается
Ну... Не то, чтобы все. Но в целом согласен. Очень нехватает чего-то вроде специального типа, чтобы все как в интерфейсном (включая контроль наследования и пр.), но не отрабатывало б на счетчиках... Приходится держать переменные в Pointer'ах...
Иван Шихалев писал(а):Climber писал(а):А данные где хранить? В записях и массивах, отдельно?
Зачем отдельно? В объектах и хранить.
Тогда я ничего не понимаю в программировании. Ну, как минимум, в интерфейсах... Можно маленький пример утечки памяти и как его можно избежать с помощью интерфейсов?
Если, спустя месяц, это все же кому-то нужно - то пример.
Если сделать так:
Будет утечка памяти, потому что не вызван SomeObject.Free.
Если же сделать так:
То утечки не будет, потому что SomeObject - интерфейсная переменная, ссылки на нее считаются автоматически и как только последняя ссылка (т.е. сама SomeObject) выйдет из зоны видимости (т.е. выполнение уйдет за end), TSomeObject.Free будет вызван автоматически.
Управление памятью на интерфейсах подробнее описано например тут:
http://softwaremaniacs.org/blog/2005/05 ... anagement/
А вообще, имхо, для устранений утечек лучше использовать heaptrc, чем управление памятью на интерфейсах.
Если сделать так:
Код: Выделить всё
type
TSomeObject = class
procedure DoSomething;
end;
var
SomeObject: TSomeObject;
begin
SomeObject := TSomeObject.Create;
SomeObject.DoSomething;
end.Будет утечка памяти, потому что не вызван SomeObject.Free.
Если же сделать так:
Код: Выделить всё
type
ISomeObject = interface
procedure DoSomething; // реализация не нужна
end;
TSomeObject = class(TInterfacedObject, ISomeObject)
procedure DoSomething; // реализация нужна
end;
var
SomeObject: ISomeObject;
begin
SomeObject := TSomeObject.Create;
SomeObject.DoSomething;
end.
То утечки не будет, потому что SomeObject - интерфейсная переменная, ссылки на нее считаются автоматически и как только последняя ссылка (т.е. сама SomeObject) выйдет из зоны видимости (т.е. выполнение уйдет за end), TSomeObject.Free будет вызван автоматически.
Управление памятью на интерфейсах подробнее описано например тут:
http://softwaremaniacs.org/blog/2005/05 ... anagement/
А вообще, имхо, для устранений утечек лучше использовать heaptrc, чем управление памятью на интерфейсах.
Последний раз редактировалось Odyssey 10.08.2009 19:55:24, всего редактировалось 1 раз.
Odyssey писал(а):Если, спустя месяц, это все же кому-то нужно - то пример.
Да, спасибо, именно это и было нужно.
И за ссылку спасибо. Кстати, я думал, что Garbage Collector в java работает так же, как подсчет ссылок в Delphi...
