Проверить выделена ли память под объект

[GunSmoker]

Сообщение от Sibedir

Поясни ...

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

Это называется "скрытая утечка памяти". Потому что технически, по определению, это не утечка. Но по поведению, эффектам - утечка.

[GunSmoker]

P.S. А потом, будет вопрос "моя программа жрёт память, но leak-и не показываются! Как найти утечки памяти до выхода из программы!".

[Sibedir]

эти 4 байта где освобождаются?

В разделе finalization

Конечно, вы делаете это в конце, но только вот смысла в этом уже нет (память и так будет освобождена).

Я могу производить ревизию ссылок при сохранении проекта в файл (в моем случае это не сложно). Могу хранить массив меток в родительском объекте проекта. В конце концов, могу вообще не использовать метки, если они не нужны. Реализовать все это не сложно. Вариаций много, это лишь пример.

Это называется "скрытая утечка памяти". Потому что технически, по определению, это не утечка. Но по поведению, эффектам - утечка.

Тогда RTTI - это тоже технология утечек памяти. Да вообще весь паскаль - одна сплошная утечка. Не знаю, мне даже с моим старьем, которое уже давно пора сдавать, 10МБ не жалко, если это положительно скажется на производительности. Ведь иных, более быстрых, способов проверить "выделенность" я не нашел.

[GunSmoker]

Сообщение от Sibedir

Тогда RTTI - это тоже технология утечек памяти.

И в каком месте RTTI выделяет память?

Сообщение от Sibedir

10МБ не жалко, если это положительно скажется на производительности.

Дело не в 10 мегабайтах. А в том, что у вас рост памяти не ограничен сверху.

Ведь иных, более быстрых, способов проверить "выделенность" я не нашел.

Вам решительно намекают на то (не один я, кстати), что в правильной программе не должно быть вопроса о выделенности памяти. Вы должны знать это явно, а не строить эвристические проверки. Да, вы можете ошибиться в коде и допустить где-то ошибку - скажем, забыть освободить объект, освободить дважды, обратиться после освобождения... много чего можно напутать. Только вот... это - ошибки. Что означает, что их нужно исправить, а не городить огород вокруг в виде эвристических проверок. Для поиска таких ошибок в менеджерах памяти есть отладочные режимы.

Я вам уже предлагал интерфейсы - там такой проблемы в принципе не стоит, но вы же...

[Sibedir]

И в каком месте RTTI выделяет память?

Да он хранит кучу информации о классах, которой пользуются раз в 100 лет. Знаю, что ее как правило не много, но ведь хранит же гад. И вообще вся оконная система в Delphi начиная с TControl грамоздкая до жути. Не, я непротив. Я к тому, что килобайты никто уже давно не считает.

Дело не в 10 мегабайтах. А в том, что у вас рост памяти не ограничен сверху.

Опять же, поправимо.

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

Ну возникла у меня такая ситуация, что не не могу я знать наверняка. TSibObject - предок сложных структурированных систем. Они могут быть просто гратескными, но при этом основное требование к ним скорость работы. Вводить ссылки на ссылки, интерфейсы и т.п. не могу. Тут речь пойдет о миллиардах операций за проход.
Ссылка на ссылку - миллиарды лишних тактов процессора.
Интерфейсы - десятки миллиардов.

[Пепел Феникса]

Интерфейсы - десятки миллиардов.

ничего подобного.

[Sibedir]

При каждом

b.f1 := a;
c.f1 := a;
d.f1 := a;
e.f1 := a;

он счетчик увеличивает. Путь не 10-ки, но всеравно - много.
Потом a может быть уничтожен. b, c, d и e должны об этом знать.
Если

a := nil;

Объект не уничтожится
Если

a.Deleting := True

b, c, d и e будут знать, но a продолжает висеть в пямяти, это ли не "утечка" (а может быть большим и таких может быть много).
Если

FreeAndNill (a);

a уничтожен, но b, c, d и e об этом не знают.

[Sibedir]

Да, кстати...
Я всетаки решил менять логику, а точнее, отладить уже используемый механизм зависимостей. Т.е. каждый объект хранит ссылки на зависящие от него объекты или же (как в примере с линиями) имеется объект-связь.

P.S.: Сори за АП. Просто подумал, может будет интересно, что же я там всё-таки надумал.

[mss]

если есть еще один указатель на этот же объект, и нет возможности/желания следить за инициализацией/уничтожением объектов, то возникает проблема. Даже если уничтожить и обнилить один из указателей на объект, другие всеравно будут продолжать хранить его старый адрес

На то существует TInterfacedObject, централизующий логику "слежения" за временем жизни объекта.