stanilar писал(а):Потому что память с забытым к удалению объектом, можно определить только по тому, что на эту память нет ссылок в программе.
В принципе можно производить "сборку мусора" по завершению скрипта.
Скрипт выполнился - все оъекты созданные скриптом освобождаются... можно сделать исключение для "експортируемых" объектов. (если например они нужны на момент выполнения следующего скрипта)
stanilar писал(а):Мне просто интересно, может у ТС кроме проблемы забытого фри, есть другие идеи использования isValidObjInst?
у ТС, как он много раз объяснял проблемы определения правильный ли указатель или нет.
Идея в целом очень здравая, т.к. он не хочет, чтобы кривонаписанный скрипт обрушил всё приложение.
А вот средства достижения не очень.
Во первых isValidObjInst опираясь на средства "по-умолчанию" написать надёжным неполучиться. Потому что память в куче, распредляется без дополнительной информации о том "для чего эта память". Тупо нехватает данных. Всегда можно нарваться на кусок памяти, который похож на объект но объектом не является.
Во-вторых, isValidObjInst можно написать надёжно, используя, например свой Memony-manager. НО, и даже проверив правильность указателя, и зная что он "да указывает на объект", всё-равно в итоге будет очень ненадёжная система.
Об этом писал зуб.
Сценарий таков:
- Код: Выделить всё
// это скриптовый код
b := CreateButton;
ComponentDelete(b);
... что ещё...
ComponentDelete(b);
к моменту ComponentDelete память могла перераспределиться, и по указателю "b" может лежать вполне правильный объект. isValidObjInst вполне правильно вернёт ему "true". Но этот объект может быть внутренним для программы (скриптового движка). А значит вызывать ему TObject(b).Free (что делает ComponentDelete) опасно.
Это больше уже не техническая проблема, а логическая.
isValidObjInst - не должен возвращать правильный ли там инстанс объекта, а он должен возвращать "лежит ли по указателю объект, который вообще-то доступен скрипту".
