соответствие iso стандарту

[noch]

Я недавно посмотрел iso стандарт и убедился то ни freepascal ни delphi ни turbopascal не соответствуют стандарту.

Как Вы к этому относитесь?

Одна из самых сильных сторон языка Ц на мой взгляд это налиюие стандарта поэтому Ц код написанный раз может быть скомпилен разными Ц компиляторами.
У нас ситуация другая. Компиляторы не совместимы друг с другом, а о совместимости с iso стандартом и реюи нет.

С другой стороны сам Николаус Вирт в статье 'долой жирные программы' писал

К сожалению, наиболее популярный язык, С++, неудовлетворителен в этом отношении, потому что было изначально декларировано, что он должен быть совместим со своим предком - языком Си. Широкое принятие С++ подтверждает следующие "законы":

    * Прогресс приемлем, только если он совместим с текущим состоянием.
<span style='color:red'>    * Приверженность стандарту - всегда безопаснее, чем даже мотивированный отход от него. </span>

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

А как Вы думаете нужно ли быть совместимым со стандартом или черт с ними с этими стандартами?

[Иван Шихалев]

Стандарту старается соответствовать GPC — ну и кто им пользуется?

[PVOzerski]

Замечу, что цитата из Вирта - большой камень в огород Delphi и Lazarus'а - еще в большей мере, чем Си++. Ведь VCL/CLX (к LCL это приложимо в меньшей мере, поскольку оправдано кроссплатформенностью) - тоже паллиативы, ответ на неспособность работать с си++-ными классами, за которых платим размерами программы. BTW, тем же платим за несоответствие базовых функций системной библиотеки тому, что лежит в услужливо предлагаемых ОС разделяемых библиотеках, будь то libc.so или msvcrt40.dll. Но последнее, видимо, - зло уже неизбежное. Не забудем, что msvcrt40.dll или crtdll.dll - тоже врапперы над WinAPI (а в NT-системах сколько функций kernel32 - врапперы над ntdll?)

Вышеизложенное можно трактовать и как призыв доделать брошенную командой FPC на ранних этапах поддержку объектов CPPCLASS - не возражаю

По сабжу. А спроста ли Borland с некоторых пор вообще отказался от названия object pascal применительно к тому языку, которым пишут в среде Delphi? Может, пришла пора оформить стандарт именно языка Delphi, а уже не Pascal? Хотя в истории с FPC есть некоторые забавные обстоятельства, а именно: новые фичи, вводимые разработчиками, зачастую через некоторое время вводятся и Борландом, но с другим синтаксисом. Примером могут послужить перегружаемые функции или enum'ы с явными значениями. Отсюда, видимо, идут и различия между {$mode objfpc} и {$mode delphi}.

[Alexander]

Мне за то и нравится Free Pascal что он не привязан к проклятым библиотекам C. Как хорошо компилировать программу и не думать запустится она или нет
на другой машине. Библиотеки эти - Ахилесова пята Линукса. Даже в отличии
от Виндовса. Если собрать C программы статически вот где будет размер.

Касаемо стандартов - их здесь пока быть не может.
Это тормоз на пути прогресса. Стандартом можно называть только одну
версию (с подверсиями) компилятора. Ну не придумал Вирт, например,
динамических массивов. А они, как оказалось, полезны. А если на каждое
нововведение стандарт создавать не хватит ни сил ни времени. И кто этим
заниматся будет ?

Если новые версии компилятора C создаются, строго говоря, непонятно зачем,
то новый Free Pascal всегда даёт что то новое. А если хочется стабильности
синтаксиса, пользуй одну версию на здоровье !

А вот обратная совместимость внутри одного диалекта - это весьма желательно.

К стандартам можно отнести только базовый синтаксис. То что делает Паскаль Паскалем.

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

[PVOzerski]

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

Касательно привязки к С-библиотекам - во-первых, я и не призывал бороться с несоответствиями системных функций (на то это и паскаль, чтобы не быть Си ), во-вторых, к C Runtime в юниксах всё равно обращаться приходится регулярно.

[Guest]

Pascal как стандарт давно мертв, да Вирт и не предлагал его для серьезной работы.
У Вирта были Modula, Modula 2, Oberon, другие люди (тоже совсем не глупые)
сделали Ada и Modula 3, в них есть все, чего в паскале недостает или сделано криво.
Не хватает разве что рисования формочек, ну так это не так трудно было бы доработать
на базе GtkAda+Glade. Вместо этого все подсели на кривой борландовский псевдопаскаль.

Ada и Modula 3 задуманы как системные языки, на них следовало бы писать ОС с ядра.
И все остальное. А сугубо прикладные программы (базы данных и т.п.) лучше делать
на динамических языках вроде Python или того же dbase. Borland своей дельфи
затащил паскаль в нишу прикладнухи, где он неизбежно погибнет.

[Uniser]

<div align="right">По поводу "паскаль мёртв"</div>
<div align="right">Тест на то, выполнена ли ваша миссия: "Если вы живы - миссия продолжается"</div>
Как известно лучшее получается не там где его ждут, а там где этим занимаются энтузиасты. Это касается всего - самый универсальный закон! Так что "религиозные войны" это удел тех, кто считает себя специалистом по демагогии. Дерзайте в работе а не в экспертных оценках. Моё мнение - есть в стандартах привлекательность (имею ввиду универсальность). Громоздкость стандарта можно спрятать за простым интерфейсом. К тому же громоздкость стандарта не означает громоздкость программ его использующих, если стандарт реализован по такому-же принципу, как скажем динамические библиотеки.

[noch]

Касательно привязки к С-библиотекам - во-первых, я и не призывал бороться с несоответствиями системных функций (на то это и паскаль, чтобы не быть Си ), во-вторых, к C Runtime в юниксах всё равно обращаться приходится регулярно.

Модуль unix не зависит от libc.
Ваша программа с использованием этого модуля обращается напрямую к ядру.
Потому, что
1. Так разработчики fpc не хотят зависеть от багов в glibc.
2. Если glibc меняется, то и они вынуждены будут меняться с ним
3. Так быстрее

Если очень надо, вариант линковать к гнусному либц есть, но не рекомендуется.

Я лично экспериментировал и успешно запускал программу написанную на RHEL 4 в RedHat 5.2 (kernel 2.0) будь то на Лазарусе или консольном фпц.

[noch]

iso стандарт есть из Виртовских языков только для modula-2 однкако наличие хорошего компилятора (сопоставимого с fpc) спорно
Вообщем я тоже склоняюсь к тому что есть стандарт или нету, это сейчас не самое важное.
К примеру из Оберон компиляторов мне нравится ulm oberon который не похож на другие

[PVOzerski]

Модуль unix не зависит от libc.
Ваша программа с использованием этого модуля обращается напрямую к ядру.
Потому, что
1. Так разработчики fpc не хотят зависеть от багов в glibc.
2. Если glibc меняется, то и они вынуждены будут меняться с ним
3. Так быстрее

Судя по исходникам RTL для *никсов, возможны оба варианта. Однако речь-то шла не именно о модуле system. Я, гл. обр., вспомнил многочисленные жалобы разработчиков проектов, юзающих некие библиотеки, более-менее стандартные для *никсов, на проблемы, которые в итоге разрешались тем, что приходилось еще и добавлять {$linklib c} в проект. И сам я сталкивался с проблемой при переносе написанных на FPC cgi-приложений UDF-ов к MySQL из Виндов во FreeBSD, когда пошел список не найденных функций (в случае UDF - в том числе и main, но это уже баг компилятора).

Ну, а касательно стандартов - всё-таки некий минимум для Object Pascal, при написании в котором можно было бы ожидать равного успеха при компиляции разными компиляторами, всё-таки хотелось бы иметь. А то бывает, когда даже c Delphi 2 на Delphi 3 проект переносится со скрипом.

[Janus]

Стандарты, конечно, полезны, однако надо понимать, что есть стандарты "де-юро", такие, как ANSI или ISO, а есть промышленные стандарты "де-факто", которыми все пользуются и которые есть не на бумажке, а в реальности. И пользователь, получая в свое распоряжение новый компилятор хочет получить не полное соответствие стандартам ISO, а мощное средство разработки, не хуже других.

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

Другое дело, что стандарт обеспечивает переносимость, по крайней мере, на уровне исходных кодов программ, не использующих специфических средств ОС. Также, стандарт мог бы гарантировать, что изучив Delphi, не придется переучиваться на FP.

P.S. А никто не знает, где бы мне в интернете найти стандарты ISO и ANSI?

[STAKANOV]

Я недавно посмотрел iso стандарт и убедился то ни freepascal ни delphi ни turbopascal не соответствуют стандарту.
...
А как Вы думаете нужно ли быть совместимым со стандартом или черт с ними с этими стандартами?

Ада жестко соответствует стандарту. Там это как религия. И что толку?

[STAKANOV]

Мне за то и нравится Free Pascal что он не привязан к проклятым библиотекам C. Как хорошо компилировать программу и не думать запустится она или нет
на другой машине. Библиотеки эти - Ахилесова пята Линукса.

Это скорей недостаток чем преимущество. Известный факт - баги фиксят быстрее в тех продуктах которые чаще используют. Что используют чаще RTL FPC или (G)LIBC ?

Работа напрямую с ядром хороша только для там где мы ограничены аппратными ресурсами (встраевыемые системы и тп). Кто-нибудь видел юниксоподобную ОС без (G)LIBC ?

[STAKANOV]

<!--QuoteBegin-Guest+--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>Цитата (Guest)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Pascal как стандарт давно мертв, да Вирт и не предлагал его для серьезной работы.У Вирта были Modula, Modula 2, Oberon, другие люди (тоже совсем не глупые)сделали Ada и Modula 3, в них есть все, чего в паскале недостает или сделано криво.[/quote]
Я пытался перейти на Ада (GNAT) - ничего не вышло. Слишком абстрактный язык. Для людей которые мыслят байтами, а не числами он не подходит.

<!--QuoteBegin-Guest+--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>Цитата (Guest)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Ada и Modula 3 задуманы как системные языки, на них следовало бы писать ОС с ядра.
И все остальное. А сугубо прикладные программы (базы данных и т.п.) лучше делать
на динамических языках вроде Python или того же dbase. Borland своей дельфи
затащил паскаль в нишу прикладнухи, где он неизбежно погибнет.[/quote]
Легенда о загнивающем западе ...

[Alexander]

Работа напрямую с ядром хороша только для там где мы ограничены аппратными ресурсами

Возникает зависимость от версии либц. Программа созданная на одной системе
не работает на другой. Это ужас. Да юниксы на С очень завязаны. Но, к
радости нашей, ядро языконезависимо. Хоть на ассемблере пиши. Да и
размер этой библиотеки всё время растёт, достигая десятков мегабайт
(если уже не сотен). Кроме того конструкция юниксов не позволяет иметь
несколько нормально работающих версий этой библиотеки одновременно.

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

И ещё ! У этой библиотеки нет обратной совместимости, старые программы
не могут работать с новой версией. Это наверное самое главное.

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

В части надёжности, функции на Паскале будут работать не хуже, чем на С.
Поскольку они самые часто используемые, то надёжность будет. А в
скорости будет скорее всего выигрыш.

Независимость от главных С библиотек и особенно от либц, даст большой
плюс ФП.