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

[jakyro]

А причем тут твой скриптовый язык?

Ну причём? Тоже не причём. Задача - "проверить указатель". А пришлось всё разжёвывать, что, да зачем...

Начнем с того что ты ошибся разделом. lazarus тут непричем. Если подобная "фича" гдето и должна быть, то это fpc.

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

Извините, где?

Извените, строкой выше, где я ответил "Назвал". Если читал мои сообщения, пытался вникнуть хотя бы в вопрос...

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

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

Т.е. вместо того чтобы просто добавить проверку указателя, тебе придётся решать побочные проблемы. Хотя всё это решилось бы проверкой указателя.

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

Как удаляется панель? Ну примерно так, в каком-то скриптовом языке (напишу sdk, а не ооп, чтоб было ясней):

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

ComponentDelete(pointer); // где pointer - ссылка на панель

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

Вы сообщения то вообще читаете? Что один, что другой... Повторно приходится писать одно и тоже.

1) т.к. уничтожение объекта происходит таки ли иначе через твою функцию, то эта функция должна собрать всех детей и их зачистить. (это чтобы LCL классы не менять

Вот оно как? А теперь скажи мне, как ты найдёшь в скриптовом языке все экземпляры объектов, которые используют данный указатель? ЕЩЁ один костыль будешь добавлять, который якабы будет проходить и освобождать экземпляры классов, дабы не дай бог они не обратились по кривому указателю и не крашнули приложение!?

И который раз повторю, именно поэтому мне нужно было решение КОНКРЕТНО поставленной задачи, а именно: узнать, на что ссылается любой указатель, дабы затем, просто не работать с ним, вместо всех тех костылей которые вы перечислили. Множество проблем, одно решение - проверить указатель.

2) если лень собирать детей, то ты можешь каждому созданному контролу повесить евент AddHandlerOnBeforeDestruction.

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

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

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

[скалогрыз]

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

Как я узнаю про удаление кнопки?

твоя прямая обязанность. И отслеживать всю информацию связанную с её удалением тоже придётся тебе

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

Решать проблему нужно только одну, а не множество, и решать её в одном месте.
Причём проблема решается, благодаря LCL-у в один цикл.

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

procedure GatherFamily(root: TControl; dst: TList);
var
  c : TControl;
  i,j : integer;
begin
  dst.Add(root);
  i:=0;
  while i<dst.Count do begin
    c:=TControl(dst[i]);
    if c is TWinControl then
      for j:=0 to TWinControl(c).ControlCount-1 do
        dst.Add(TWinControl(c).Controls[j]);
    inc(i);
  end;
end;


Естественно, как ты писал раньше, тебя такой код коробит.

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

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

Это не выдумывание проблем, это способ КОНТРОЛЯ. КОНТРОЛЯ за тем что происходит между скриптом и LCL-ом.
Он может быть либо активный (проверю детей, когда родиеля убьют), либо пассивный (дитё само меня оповестит когда собирается помирать).
И имея на руках список указателей, которые я передал скрипту, я всегда со 100% точностью могу сказать - правильный ли это указатель или нет (при условии что я поддерживаю его в актуальном состоянии)

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

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

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

[zub]

Ну и ты ошибся разделом, раздел "флуда" в другом месте.

ок, флуданул я про эмоции, но уважай отвечающих тебе.

Типа это fpc поставляет библиотеку LCL? Я и спрашивал про указатель на компонент LCL в соответствующем разделе.

А при чем тут лцл? при том что у тебя панельки и кнопки? это контролы дружбан, компоненты это другое. а ты думаю тимел ввиду просто классы, и по ссылке твоей не контролы и компоненты а классы))
Глянь кстати где определен TComonent

Ты что хочешь показаться умным или что?

Неа я просто хочу сказать "что Ссылается ли указатель на компонент?" к LCL никак не относится. указатели и компоненты это масло масляное. Хоть ты и называешь всё криво и объясняешь таксибе, но мы та понимаем что ты имеешь ввиду))

Извените, строкой выше, где я ответил "Назвал". Если читал мои сообщения, пытался вникнуть хотя бы в вопрос...

Вопрос звучал так: Назови мне хоть одну причину по которой мусор лежащий там куда ссылается указатель лежащий в 1235678 не может быть похожим на валидную вмт?
Нету там ответа.

Ладно, фиг с ним. Пусть ты нашел способ проверять является ли ссылка валидным пока не уничтоженым инстансом какоголибо класса. Дальше что? Обяжешь пользователя при каждом чихе в скрипте проверять валидность?
что помешает пользователю крэшнуть твое хозяйство просто запустив такой скрипт наподобии

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

MyButton:=TButton.Create;
MyButton.Free;
MyButton.Free;

Добавлено спустя 11 минут 12 секунд:
зы.
>>Как удаляется панель? Ну примерно так, в каком-то скриптовом языке (напишу sdk, а не ооп, чтоб было ясней):
Нука покажи как определение

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

ComponentDelete

Просто это смахивает на то что ты таки используешь принцип хэндлов и сам того не понимая морочишь людям головы))

[stanilar]

Может у меня тоже начал развиваться рассеянный склероз от обильного количества буковок, но кто-нибудь уже задал вопрос о том, что если память по указателю оказалась перераспределена под другой объект, и проверка на валидность положительна по определению, то есть ли смысл во всех разговорах о том, что с помощью такой проверки можно проверить существования некогда ранее существовавшего объекта/компонента/контрола?

[скалогрыз]

Нука покажи как определение

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

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

ComponentDelete

Вангую:

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

procedure ComponentDelete(comp: Pointer);
begin
  if IsValidPointer(comp) then
    TControl(comp).Free;
end;


Если бы было подругому по этой темы бы не было.

[zub]

..убрал, т.к. вангую также как скалогрыз

[скалогрыз]

Я вангую подругому, чтото типа:

а в чём разница-то ?
вижу у тебя ошибку кстати! у тебя используется неправедный TObject

[zub]

да разницы нету.
Если скрипт не допускает прямых вызовов методов, а работает через обертки типа ComponentDelete - comp это и есть хэндл. И брюки легким движением руки превращаются в шорты))

[jakyro]

ComponentDelete - это кстати был вымышленней пример...
И причём тут реализация? Опять вы за своё... Я говорю о динамике. О том, чтобы пользователь имел право ошибиться В СКРИПТОВОМ ТО ЯЗЫКЕ и отловить ошибку, на очередной проверке указателя, а не закрыло ему прогу!

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

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

это контролы дружбан, компоненты это другое.

Дружбан, ты знаешь что такое наследование? Контролы и есть компоненты, компоненты и есть объекты. И всё это различные уровни классов, дабы как-то сгрупировать функционал.
Компоненты - не перестают быть компонентами, от того что их назвали контролами и разрешили размещать на них другие компоненты.
Набери в гугле "компоненты для delphi", что ты найдёшь? Верно, компоненты для делфи, а не контролы... Это всего лишь типизация, группировка функционала...
Дружбан, я тебе ещё раз говорю, что я разрабатываю проект в среде разработке lazarus, а не на её отдельно взятом компоненте (если ты не понял смысл слов, поясню, что под компонентами в данном случае, я имею ввиду составляющие части среды разработки lazarus).
Если бы я заранее знал, какую функцию нужно использовать и какой конкретно библиотеке в среде lazarus, я бы вообще этого вопроса не задавал, так как я бы знал где есть такая функция.
А так как я этого не знаю, я и спрашиваю относительно своего проекта, среды, в котором я его разрабатываю, а именно lazarus.

Обяжешь пользователя при каждом чихе в скрипте проверять валидность?

А разве ты не тоже самое делаешь с массивом указателей?

Просто это смахивает на то что ты таки используешь принцип хэндлов и сам того не понимая морочишь людям головы))

Так код и не написан.

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

То, что это не касалось задачи "проверить указатель". Что за левые вопросы то, оффтоп?


Смотрим шапку, есть конкретный вопрос... Мне надоело повторяться. Демагоги.
Любое последующее сообщение не по теме того, "как проверить, ссылается ли указатель на компонент", буду игнорировать и принимать какие-то меры.

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

[zub]

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

>>буду игнорировать и принимать какие-то меры.
Ты и так всё что можно проигнорил))

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

[скалогрыз]

Я говорю о динамике. О том, чтобы пользователь имел право ошибиться В СКРИПТОВОМ ТО ЯЗЫКЕ и отловить ошибку, на очередной проверке указателя, а не закрыло ему прогу!

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

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

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

Замечательно, я весьма рекомендую на этом решении прогнать тест zub-а.

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

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

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


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

[zub]

еще тестик

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

program Project1;
function IsMagicValidPointer(p:pointer):boolean;
begin
  //тут твоя проверка
end;
var
  i,counter:ptruint;
begin
  counter:=0;
  for i:=0{поменьше} to maxint{побольше} do
   if IsMagicValidPointer(pointer(i)) then
     inc(counter);
  writeln(counter);
  readln;
end.

[скалогрыз]

еще тестик

ты излишне щедр

[Лекс Айрин]

Я говорю о динамике. О том, чтобы пользователь имел право ошибиться В СКРИПТОВОМ ТО ЯЗЫКЕ и отловить ошибку, на очередной проверке указателя, а не закрыло ему прогу!

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

[alexey38]

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

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

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

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

Насколько я знаю, корректным будет способ реализации, либо как в виндовых интерфейсах (со счетчиком ссылок), либо с реализацией функции обнуления всех указателей, при удалении объекта. Второй способ реализовать проще, и будет все это работать со 100% корректностью.