один прикладной вопрос по ООП

[Максим]

В тех случаях, когда обработка такого указателя доходит до Free, -- явно что-то не то с логикой кода.

В тех случаях, когда обработка нулевого указателя доходит до Free, -- явно что-то не то с логикой кода.

[debi12345]

В тех случаях, когда обработка нулевого указателя доходит до Free, -- явно что-то не то с логикой кода

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

[Vapaamies]

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

[Mirage]

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

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

Java, например, такого не соберёт и я это говорил...

Java, кстати, это прекрасно соберет и не менее прекрасно упадет по NullPointerException:

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

  Foo foo = null;
  foo.foo();


Хотя и выдаст варнинг про null pointer access в данном очевидном случае.

[Рождённый_в_СССР]

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

а вы подумайте почему не просто? )
скажем в Haskell экземляр класса типов мне показывает даже Geany... а сам "исполнитель" его не создаст без видимой на то причины... поэтому отследить там это очень просто...
раз уж мы говорим о Паскале как о безопасном языке - должны тогда вносить какую-то новую семантику, чтобы можно было отследить создавался ли экземпляр класса... потому что, повторяю для модели ООП этот код верен... ведь аналогичное сделано в Oberon , который близок как никакой к Паскалю и имеет куда более короткую семантику, правда там это тоже решено на уровне исполнителя... а вот FPC компилит и молчит, как партизан...
и кстати в примере решения от Vapaamies он тоже не создаётся... а вызов работает...

вы наверное не въехали в глубину того что произошло ) направление понятия этой проблемы - понимание, что есть разница между ссылкой и указателем, не большая, но есть... и в Паскале нет адекватной замены операции "->" в Си на классах... нет... есть ".", но это совсем другая семантика вызова и она так-же аналогична Сишной "."... а вот "->" на классах у Паскаля нет... хотя и в Си проблемы с перегруженностью всего подряд от этой самой "." и "->" до "&&", спецы Си разбираются часами где какая операция что значит и какой у неё приоритет в данном случае...

[alexey38]

вы наверное не въехали в глубину того что произошло ) направление понятия этой проблемы - понимание, что есть разница между ссылкой и указателем, не большая, но есть... и в Паскале нет адекватной замены операции "->" в Си на классах... нет... есть ".", но это совсем другая семантика вызова и она так-же аналогична Сишной "."... а вот "->" на классах у Паскаля нет... хотя и в Си проблемы с перегруженностью всего подряд от этой самой "." и "->" до "&&", спецы Си разбираются часами где какая операция что значит и какой у неё приоритет в данном случае...

А с чего это паскалевская "." при работе с классами соответствует сишной "."? Это и есть сишная "->". В паскале для классов как раз нет "." и "&" в сишной терминологии.

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

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

if pClass<>nil then begin ... end else обрабатываешь ошибку

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