Правильный free

[Vadim]

Ну а зачем же я пример программы приводил?

Я не знаю... Вы ведь результат работы программы не привели...

[serbod]

почему НЕЛЬЗЯ ОБНУЛИТЬ SELF ПРИ ВЫЗОВЕ ДЕСТРУКТОРА?

Потому что при правильном использовании классов в этом нет никакой необходимости. После уничтожения экземпляра класса, занимаемая им память в "куче" возвращается системе. И дальше забота системы, что с этой памятью делать - обнулить, выдать другой программе или оставить "на потом" на случай, если некорректно написанная программа продолжить эту память использовать (как было в win95).

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

[olegy123]

А действительно, не потрудится ли топикстартер рассказать, что он имеет в виду...

потому что, си/паскаль создавались еще тогда когда даже менеджеров памяти не было, удел программиста создать данные поработать с ними и за собой убрать.
Если вы копируете объекты.. то копируете не сам физический объект - а его ссылку, номер памяти в котором что то находится. копирование - это копирование просто номера SimpleRef := SimpleInt;. Этот номер можете поделить, умножить сложить..
Когда делаете SimpleInt.free запускает деструктор который нужен для программиста чтобы ручками мог подчистить данные.. а можно и не скидывать.. но если данные создавались динамически - то легко получить утечку памяти

что делает SimpleRef.Value? - по коду берет из номера памяти со смещением на Value значение.
..

Добавлено спустя 7 минут 59 секунд:

Уточняю постановку вопроса: Кто-нибудь понимает, почему НЕЛЬЗЯ ОБНУЛИТЬ SELF ПРИ ВЫЗОВЕ ДЕСТРУКТОРА?

потому что лень..
В курсе что простым динамическим созданием/удалением в линухе программа может скушать всю память, только потому что менеджеру памяти линуха лень дефрагментировать. Создатели посчитали, что эта операция очень затратная по времени.
Поэтому self обнулять после деструктора - лишние операции на старых компах с 3Мгц считалось роскошью.

[Лекс Айрин]

Но все классы являются потомками TObject и я не понимаю почему нельзя разрушить (хотя бы self обнулить) сам объект, а не только ссылку на него. Причем сделать это абсолютно прозрачно, не требуя от программиста дополнительной работы.

Потому что размер объекта величина не постоянная и может меняться в процессе выполнения программы. И никто не гарантирует, что удастся корректно удалить весь объект. Конечно, можно отслеживать все выделения/освобождения памяти, но это очень сильно замедляет программу. Поэтому это дело отдано на откуп программисту. Ну а контроль всех ссылок на одно и тоже место (и их удаление при освобождении объекта/переменной) может вообще порушить программу, если эти данные зачем-то нужны программисту.

[zub]

>>Потому что размер объекта величина не постоянная и может меняться в процессе выполнения программы. И никто не гарантирует, что удастся корректно удалить весь объект.
трэд фантазий

[Лекс Айрин]

zub, не мой, а автора одного из учебников по TP. Кажется, по 7 версии. Там было, в том числе, что-то связанное с присваиванием родителя предку или наоборот...

[zub]

Не важно чем вызваны фантазии, то что это фантазии не отменяется.
Читаем посты Дож на первой странице и переименовываем топик, т.к. то что хочет автор это никак правильным не является.

Выделил ТС память. распихал ее адрес по десяти разным указателям. потом развыделил... и хочет чтобы во всех указателях nil по волшебной палочке появился?

[Лекс Айрин]

zub, это сразу понятно, что он хочет странного. Лень очень этому способствует.

Не важно чем вызваны фантазии, то что это фантазии не отменяется.

Просто учту на будущее.

[Vapaamies]

Поскольку тема в разделе «Компилятор / язык программирования», позволю себе немного попиариться.

Реализация умных указателей (smart pointers), о которых говорит DedFrend, планируется в Халва-Паскале. Он будет компилировать при помощи платформы Кантора, в которой будет автоматическое управление памятью на основе графов достижимости, — функционально аналогичное Rust, но сделанное проще, по-паскалевски. Пока непонятно, какие именно техники будут использованы в Канторе и какие входные данные потребуются при компиляции в Кантор из Паскаля, поэтому об исключении Free и FreeAndNil сходу заявить не могу. Если же удастся сделать как хочется, в халвовом синтаксисе Паскаля Dispose, Free и FreeAndNil наверняка будут запрещены, а память и ссылки станут отслеживаться неявно.

[Лекс Айрин]

Vapaamies, а как же возможность получить кусок памяти и делать с ним все, что возможно?

Добавлено спустя 4 минуты 53 секунды:
Кроме того, тогда о какой совместимости с ObjectPascal идет речь?

[Cheb]

Кто-нибудь понимает, почему НЕЛЬЗЯ ОБНУЛИТЬ SELF ПРИ ВЫЗОВЕ ДЕСТРУКТОРА?
И я имею в виду не программиста, а разработчиков.

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

[Vapaamies]

Vapaamies, а как же возможность получить кусок памяти и делать с ним все, что возможно?

«Всё, что возможно» укладывается в 2 пункта:

• Манипуляции над массивами/строками через адресную арифметику.
• Передача адресов во внешние API (ОС, библиотеки).

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

Передача во внешние API остается без изменений, будет лишь конструкция handle by для объявления финализатора типа:

Код: Выделить всё

public class HGLOBAL from :Core:LongWord handle by GlobalFree;


Пример кода — уже на Канторе. Как он ляжет в Халва-Паскаль и ляжет ли вообще, вопрос пока открытый.

[Лекс Айрин]

«Всё, что возможно» укладывается в 2 пункта:

Не забудь еще, что надо сообщить компилятору, что память уже не нужна. Это процедура Dispose.
Потом, я могу в этом блоке памяти разместить тупо блоб, который динамически изменять, осуществляя доступ к его частям по смещению относительно базового. Примером такого блоба можно считать исполняемый файл, который собирается компилятором.

Передача во внешние API остается без изменений, будет лишь конструкция handle by для объявления финализатора

И что это дает? Финализацию, в fpc, можно тупо сделать в каждом модуле и в программе забыть об этом.
Кстати, ты уж определись туда или обратно... Либо ты придерживаешься спецификации Object Pascal, либо Канторовской. Вместе как-то не получается. Будет гибрид слона и кита.

На переходный период будет также небезопасное расширение стандарных классов, допускающее адресную арифметику.

А вот это, имхо, совсем зря. Классы создавались чтобы убрать все, в идеале, манипуляции с адресами от пользователя. Т, е, это уход от адресной арифметики. (пусть если что меня zub поправит).

[DedFrend]

Всем спасибо за обсуждение.
В общем-то я боялся, что ломлюсь в открытую дверь. Оказывается дверь действительно существует.
Но я не прощаюсь! Скоро я по этой проблематике еще новую тему создам.

[Vadim]

Скоро я по этой проблематике еще новую тему создам.

Пока что проблему следует признать недостаточно аргументированой и обоснованой. Учтите это при создание новой темы...