Ссылается ли указатель на компонент?

[MiniQ]

Еще один вариант - работать с указателями на указатели.
В скрипт передавать PObject - указатель на TObject.
При освобождении TObject вызывать FreeAndNil(TObject).
Тогда проверка PObject^<>nil будет проверкой на валидность.

[Лекс Айрин]

MiniQ, не забывайте, что указатель на указатель тоже может быть невалидным... например, указывать на уже удаленную переменную. Так что все равно приходим к сборке мусора и массиву активных ссылок.

[MiniQ]

MiniQ, не забывайте, что указатель на указатель тоже может быть невалидным... например, указывать на уже удаленную переменную. Так что все равно приходим к сборке мусора и массиву активных ссылок.

Мда, согласен.

[Лекс Айрин]

MiniQ, вообще, "сырые" указатели имеют смысл только для адресации в некотором оборудовании. Например, в dos при работе с видеопамятью. Ну или в пределах выделенного блока памяти.

[zub]

MiniQ
>>Еще один вариант - работать с указателями на указатели.
Это всё вариации хендлов - пользователю выдается некий идентификатор некой структуры данных. Как это организовано - как в винапи, через "многоэтажный" указатель или както подругом неважно.

Лекс Айрин
>>вообще, "сырые" указатели имеют смысл только для адресации в некотором оборудовании
Я вот слабо представляю жизнь без указателей (те которые pointer и ^TDataType) это быстро и надежно если не злоупотреблять. Например выдача указателя на структуру данных с ограниченым временем жизни кудато "наружу" - типичное злоупотребление

[Лекс Айрин]

Я вот слабо представляю жизнь без указателей

не думаю, что ты говоришь о "сырых" (неконтролируемых) указателях. Фактически, подозреваю,что ты работаешь с выделенным блоком памяти.

[wavebvg]

В общем случае - невалидный указатель может быть с потолка, тогда нужно использовать какую-либо условность для валидации.

1. К примеру, создавать все формы с Owner-ом Application и потом проверять, есть ли в данный момент у Application-а такая форма:

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

Application.Components

Ну или завести отдельный список, как говорили раньше.

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

2. Хранить ссылку на компонент F (а форма и есть компонент) могут только другие компоненты A. При назначении в качестве свойства/добавлении в список комопненты F, компонент A подписывается на оповещения и обрабатываем события удаления (записывает NIL в свойство, удаляет ссылку из списка и т.п.)
3. Использовать автоматическое управление памяти, к примеру как в новой дельфе, но тут нужно очень много о чем помнить.

[jakyro]

Рад. чесно! но чеж ты стесняешся нам решением то похвастать?

И ещё раз повторю... Сообщения читай! 2 страница.

ну так тебе и говорят об этом. zub, все зубы уже обломал, пытаясь тебе помочь!

Я теже самые зубы ломал, чтобы объяснить, что мне вся эта ерунда не нужна! Мне нужно именно проверить ЛЮБОЙ указатель на то, на что он ссылается, БЕЗ дополнительной реализации кучи менеджеров указателей, БЕЗ дополнительной реализации обработчиков удаления компонентов, а с ними и указателей, БЕЗ всех этих прилагающихся проблем.

Тест следующий. Выполни, пожалуйста, вот такой код в скрипте (т.к. мы синтаксис не знаем, то будем импровизировать):

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

b = CreateButton;
componentDelete(b);
componentDelete(b);

как после этого кода себя ведёт программа? И не стесняйся поделиться результатами.

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

Это плохой язык. Если пользователь (программист) ошибся, то прога должна клеить ласты. И никак иначе. В противном случае есть нехилый шанс, что ласты склеит система. Указатели очень опасный механизм.

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

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

Обсуждаемый вопрос, на мой взгляд, сформулирован некорректно. Отсюда и весь последующий флуд.

Корректно и с примером в придачу. И с 4мя страницами объяснения того, что мне не нужно всё то что они тут пишут, так как мне нужно конкретно "проверить, на что ссылается указатель" и на 2рой странице я показал одно из решений.
НО ДО СИХ ПОР, они чего-то там обсуждают, о каких-то там списках, менеджерах, хендлах, вся та ерунда, что мне не нужна.

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

Нет. Валидацию не пройдёт.
А если ты думаешь, что пройдёт, так пиши такую валидацию, чтоб не прошло.
Помимо валидации, далее идёт преобразование указателя к конкретному классу, если он валиден и класс соответствует выявленному классу во время валидации.

А задача проверки на то, ссылается ли указатель на тоже самое, на что он ссылался при его присвоении - это другая задача, и решается она другим способом.

Я уже сказал, почему это не важно и валидации вполне хватит.


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

[скалогрыз]

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

"удалит", "сообщит" и "продолжит", это замечательно, но в теории.
Просьба же была протестировать, т.е. ожидались слова "удалил", "сообщил" и "продолжил" - есть результаты?

По результатам судят о труде. И если они (результаты) успешные, то очень интересно знать решение этой нетривиальной проблемы - распознаение типа указателя без дополнительной инфраструктуры.

[Лекс Айрин]

Мне нужно именно проверить ЛЮБОЙ указатель на то, на что он ссылается, БЕЗ дополнительной реализации кучи менеджеров указателей, БЕЗ дополнительной реализации обработчиков удаления компонентов, а с ними и указателей, БЕЗ всех этих прилагающихся проблем.

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

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

Скорее он свалит систему. Это видно даже такому новичку как я.

Опасно было бы не проверять на валидность, а тупо хранить список указателей и надеяться, что где-то случайно не будет упущена его очистка из списка.

Сборка мусора в таких системах не настолько плоха. Если, конечно, не играть со случайными ссылками.

А так же опасно то, что многие компоненты создают суб объекты, которые тоже имеют свои указатели, которые тоже нужно проверить на валидность и они будут не валидны, если родитель удален.

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

Нет. Валидацию не пройдёт.
А если ты думаешь, что пройдёт, так пиши такую валидацию, чтоб не прошло.

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

Ограничивать пользователя в владельцах - тоже не особо хороший тон, к тому же тогда и в памяти будет оставаться хлам, так как родители компонентов не будут являться их владельцами и при удалении не удалят детей, кроме ручного удаления всех детей, либо удалении владельца, которым является Application.

Ой ли... как раз таки "у семи нянек дитя без глазу"... А если ты хочешь написать язык, который нарушает принципы ооп, то:
1) Тогда уж и Application не будет уничтожать все компоненты.
2) А как ты узнаешь, что родителей у объекта не осталось?
3) А как можно, допустим, кнопку разместить в двух (и более) местах?

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

[скалогрыз]

никак нельзя... задача не имеет надежного решения.

ты так говоришь, потому что тебе zub сказал? или есть какие-то технические обоснования?

ты же видел раньше по тексту, что jakyro решил задачу сам, и сейчас ждём результатов проверки!

[jakyro]

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

Ну так я тестировал уже. Я ведь привёл примеры теста, ну блин, вы реально бесить уже меня начинаете, ненароком напишу чего плохого...
А также я горил, что СТАРЫЙ ДВИЖОК РАБОТАЕТ ПО ТОМУ ЖЕ ПРИНЦИПУ и никакое из ваших перечисленных опасений - не оправдалось. Всё работало стабильно, за исключением старых функций, которые не были переведены на новый формат валидации, в их случае программа просто повисала на веки вечные.

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

Можно. Я уже продемонстрировал как. А также старый движок успешно использует подобный трюк.

Скорее он свалит систему. Это видно даже такому новичку как я.

Ты новичёк, а я нет. Я 3 года поддерживал старый графический движок на delphi. И ещё через несколько лет захотел возродить движок, на бесплатной альтернативной библиотеке, чтобы можно было нормальную лицензию приписать.
Возможно ты в чём-то ошибаешься.

Сборка мусора в таких системах не настолько плоха. Если, конечно, не играть со случайными ссылками.

Я не говорю, что это плохо. Я говорю, что это затратно по времени и ресурсам. В то время как можно реализовать не менее безопасное и не менее быстрое решение с проверкой каждого указателя.
К тому же ты не знаешь проект, ты не понимаешь что за мусор нужно собирать. Помимо одной системы со стороны SDK тебе нужно будет реализовывать обратное взаимодействие со скриптовым языком, как-то освобождая экземпляры классов из всех объявлены переменных, массивов. Я не хочу всё это тебе пояснять, то как работает скриптовой язык, не скриптовой, как оин взаимодействуют, как работает движок, библиотека и как они взаимодействуют и т.д.

Очень много факторов нужно вам описать, объяснить, как и почему ... Чтобы вы возможно поняли, почему меня всё таки больше устраивает проверка указателя, чем список указателей.

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

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

Ой ли... как раз таки "у семи нянек дитя без глазу"... А если ты хочешь написать язык, который нарушает принципы ооп, то:
1) Тогда уж и Application не будет уничтожать все компоненты.
2) А как ты узнаешь, что родителей у объекта не осталось?
3) А как можно, допустим, кнопку разместить в двух (и более) местах?

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

Владелец, в случае компонента, это место (область/компонент) где компонент размещается физически

Владелец (Owner) - это тот компонент, который отвечает за управление дочерним компонентом, например, владелец вызовет деструктор дочерних компонентов, если владелец собирается удалиться.
Родитель (Parent) - это тот компонент, на котором отрисовываются в том или ином виде дочерние компоненты, но при удалении родителя - на дочерние компоненты это никак не повлияет, они останутся в памяти и им можно успешно поменять родителя.

Добавлено спустя 4 минуты 37 секунд:

что jakyro решил задачу сам, и сейчас ждём результатов проверки!

Мне всего лишь нужно было протестирвоать валидацию, остальное успешно работает.
Валидацию успешно протестировал и привёл сырой пример, как узнать на что ссылается указатель.
Я не понимаю какие ты ждёшь результаты. Работает код так:

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

cmp = 12345
{ ComponentDelete(cmp) }
Если Указатель(cmp) верен, то
   Удалить(cmp) { иначе, например сообщить в отладку о удалении не существующего компонента }
{ ComponentDelete(cmp) }
Если Указатель(cmp) верен, то
   Удалить(cmp)


[Лекс Айрин]

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

Так как указатель это просто адрес, то проверить его можно только полностью проверив область памяти или ее ключевые точки. Но, так как если указатель повис, то он продолжает указывать на тоже место памяти, то (если не учитывать зачистку самой области) он продолжает "видеть данные". И даже в случае перераспределения нет никакой уверенности, что этот указатель не будет указывать на другую переменную, например, сдвинутую на один/два/четыре байта. В случае если память эту память у программы отобрали то программа получит нарушение общей защиты. Либо от системы, либо от менеджера памяти самой программы. Если его не обработать, то клей и ласты находятся моментально. Есть еще моменты, если поразмыслить.

ты же видел раньше по тексту, что jakyro решил задачу сам, и сейчас ждём результатов проверки!

Я больше доверяю даташиту интел и компании Microsoft... как бы я ко второй не относился.

Да и задача странная... откуда может появиться указатель, который неизвестен программе/программисту? При том, что он, почему-то может указывать на какой-то компонент! Подозреваю, что в некоторых компаниях за подобное руки отбивают... И клаву отбирают.

[jakyro]

Да и задача странная... откуда может появиться указатель, который неизвестен программе/программисту?

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

[скалогрыз]

Ну так я тестировал уже. ... Я не понимаю какие ты ждёшь результаты. Работает код так:

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

cmp = 12345
{ ComponentDelete(cmp) }
Если Указатель(cmp) верен, то
   Удалить(cmp) { иначе, например сообщить в отладку о удалении не существующего компонента }
{ ComponentDelete(cmp) }
Если Указатель(cmp) верен, то
   Удалить(cmp)


Мне кажется ты тестировал на тестах, которые ты подогнал под ответ, вместо тех тестов, которые мы тебе рекомендуем.
У тебя сильно секретный/сложный скрипт, может ты тестовый скрипт (именно скрипт, а не паскаль код) выложишь?