zub писал(а):Не валидлный указатель это баг - надо исключить возможность его появления а не пытаться проверить на валидность.
Т.е. ты признаёшь, что есть такое понятие как "валидный" и "не валидный" указатель, и оно допустимо, и как-то проверяется.
Вот у меня как раз та ситуация, где могут всплыть и не валидные указатели, и чтобы не крашить приложение, мне нужно эти ситуацию как-то обыграть, проверять указатели.
zub писал(а):Отладчик ниче не проверяет, если указатель указывает на область данных приложения, но не на валидные данные, он покажет мусор. Если на невыделенную память - скажет что неможет прочитать.
Верно. Это и нужно, для проверки указателя.
zub писал(а):Уничтожаешь данные в куче - будь добр обниль все указатели на них. тогда проверка на nil равна проверке на валидность
Организовать свой менеджер памяти? Что-то ты не верно понял вопрос... Пользователь вводит любой указатель, а программа должна определить, является ли указатель валидным, а не то что я там имею какую-то кучу указателей и их чекаю (именно этого я и хочу от менеджера памяти lazarus... ).
Это всё понятно, что я бы мог завести тот же банальный массив указателей и проверять, есть ли там такой указатель, если есть, то скорей всего он валиден (скорей всего, так как может и нет, так как его могут уничтожить и другие компоненты, библиотеки, процессы, <и тут ещё множество других вариантов>).
Но это был бы очередной костыль. Примерно тоже самое что и с исключениями в делфи (и нет, это не случай, там всё действительно можно обработать в исключениях (ответ к следующему комменту)).
Просто, возможно, в delphi 2007 лучше реализован механизм исключений, чем lazarus, либо иначе настроен, менее чувствителен, имеет другие варианты решения, помимо модальной ошибки.
А так же может влиять функциональность менеджера памяти и именно поэтому во многих ответах, в интернете, советуют использовать альтернативный менеджер памяти, с расширенными возможностями.
Просто я думал и всё ещё думаю, что в lazarus, pascal всё такие есть какой-то механизм, чтобы это реализовать, прочитать указатель, если он читаем и содержит указанную структуру.
И нужно кстати это для некого скриптового языка. Скриптовой язык ведь более динамичен и позволяет менять всё на ходу, а так же есть механизмы, трюки, хаки, дополнения для изменения того, что не меняется.
Можно сказать типа "не менять этот указатель любым возможным способом" (типа как константы в питоне, если понимаете о чем я), а можно реализовать валидацию. На худой конец тот самый массив указателей.
Ещё один банальный способ предложу, типа "читать определенный участок памяти, если он читаем и искать там зацепку, типа класс TForm, последовательность байт, сигнатуры и прочие".
Зашёл на форум, где вроде бы сообщество людей знающих pascal, lazarus. А в действительности сам же что-то объясняю, предлагаю варианты решения, а не пишу глупые отписки типа "ну сделай чтоб так не было"...
Мне нужно именно проверить указатель, чтобы сделать приложение более динамичным (и даже в случае, когда пользователь удалил компонент и пытается на него сослаться - приложение не крашилось, а обрабатывало исключение, не давая работать с не валидным указателем).
Неужели для языка такого уровня это не возможно?
Или просто вы с этим не сталкивались, не работали, возможно чего-то и не знаете... Можно такое предположить?
Это ведь не значит, что "так делать не надо" и "это не возможно".
Решение то я реализую в любом случае, просто думал мож тут скажут что-то, чего я не знал.
Добавлено спустя 21 минуту 25 секунд:скалогрыз писал(а):если try..catch и работал в Delphi, сообщая о неправильном указателе, то это просто везение.
Нет, это не везенье, так можно обработать практически любую ситуацию, кроме фатальных (просто после фатальных приложение перестанет нормально функционировать, а так и это можно обработать).
Весь старый ui движок для скриптового языка работал на подобных трюках, позволяю приложению спокойно продолжить работу, а не крашиться при любом не валидном указателе.
Но он старый (2004)(а как же так, ведь делфи 2007, а вот так, был портирован с delphi 7), и библиотеки платные, и среда дорогая... Вот и хотелось бы переписать на альтернативной среде.
скалогрыз писал(а):При работе с объектами, у тебя вообще не должно быть ситуации проверять правильный/неправильный указатель. В общем-то ты и с указателями не должен работать.
Верно, я работаю не с объектами, а с указателями. А является ли указатель объектом или ничем, это уже нужно проверить.
Чтобы можно было это представить, опишу банальный пример, делаешь API или SDK, где взаимодействие производится только по указателям, вот собственно и не плохо было бы чекать эти указатели, так как весь SDK не может следить за всем тем, что творится в памяти LCL... Может. Если написать портянку... Вот поэтому такая банальная возможность, как проверка существования компонента по указателю, была бы совсем кстати.
скалогрыз писал(а):Для решения проблемы я рекомендую переписать код, чтобы проблема исчезла как таковая.
Если кода нужно много переписывать, то я рекомендую переписать код.
Так код и не написан.
Так как старый трюк с исключениями тут не работает, вот я и зашёл спросить, делать мне хранилище указателей, хоть для какой-то валидации, либо такой механизм присутствует в менеджере памяти lazarus и я могу проверить указатель на предмет присутствия в нём конкретной структуры.
По сути ведь это банальная задача для языка такого уровня: проверить читаема ли память, прочитать участок памяти, убедиться что в нем нет конкретной структуры или есть.