LINUX.ORG.RU

Релиз 2.2.4 свободного компилятора Free Pascal

 ,


0

0

На радость школьникам и студентам 12 апреля, в День Космонавтики, вышел новый стабильный релиз свободного компилятора языка программирования Free Pascal, который считается средством разработки кросс-платформенных приложений.

Страница для загрузки

В основном эта версия посвящена исправлению ошибок.
Список изменений, которые могут повлиять на уже существующие проекты
Логи изменений в Subversion

>>> Сайт проекта

★★★★★

Проверено: svu ()
Ответ на: комментарий от madcore

> Железный аргумент..

Ладно, раз он не нравится (видимо), то тогда смотрим на http://lxr.linux.no/linux+v2.6.18/include/linux/list.h и думаем, как сделать на паскале хотя бы так же и насколько страшно оно будет выглядеть. Если просто и красиво -- значит я был не прав.

sv75 ★★★★★
()
Ответ на: комментарий от Tu3eK

Молодой человек, ваши категоричные и во многом спорные заявления характеризуют вас не самым лучшим образом. Если вы чего-то не знаете или просто не любите, не навязывайте своего мения другим людям. Приводите аргументы и показывайте с лучшей стороны то, что вам нравится. Тогда у вас и появятся сторонники.

awdd
()
Ответ на: комментарий от hobbit

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

Tu3eK
()
Ответ на: комментарий от awdd

> Освобождением ресурсов при ошибках должен заниматься компилятор (в код вашей программы внедрять соответствующий код).

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

> Когда этим занимаются сами программисты - вот тогда и получается, одни программы работают хорошо, другие - вообще никак.

Так получается, когда люди про модульное и регрессионное тестрирование узнают поздно.

sv75 ★★★★★
()
Ответ на: комментарий от awdd

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

Tu3eK
()
Ответ на: комментарий от sv75

Мы наверное просто о разных вещах. Многое. о чем я говорю, как раз реализовано в Java с точки зрения безопасности и надежности кода.

awdd
()
Ответ на: комментарий от sv75

Да нет, то, что на ЛОРе любят обгадить всех и все - я прекрасно знаю. Вот культуру дискуссии и уважительное отношение к оппонентам к сожалению встретишь редко.

awdd
()
Ответ на: комментарий от awdd

> Многое. о чем я говорю, как раз реализовано в Java с точки зрения безопасности и надежности кода.

А вот там реализовано как раз совсем-совсем другое, а не то, что вы написали. И кстати -- принудительное освобожнение ресурсов в момент времени X там (как и в C#) "вручную", по явному указанию разработчика, и в качестве костыля.

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

sv75 ★★★★★
()
Ответ на: комментарий от Tu3eK

> в ява модули это пакеты, в шарпе это сборки. модуль как файл это архаизм 80-х годов.

Тем не менее, этот "архаизм" очень неплохо выполнял и выполняет свою функцию.

А по смыслу пакеты явы очень близки модулям из паскаля и модулы-2.

hobbit ★★★★★
()
Ответ на: комментарий от sv75

> Структурному? А кстати, как на Виртовском паскале красиво освобождать при ошибках занятые ресурсы, если не использовать goto, как нам велит структурное программирование?

На Виртовском - никак, тут Вы правы.

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

А в позднейших реализациях паскаля уже появились как обработка исключений, так и способы красиво обойтись без goto вроде всяких break/continue и exit.

hobbit ★★★★★
()
Ответ на: комментарий от sv75

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

awdd
()
Ответ на: комментарий от sv75

>Ладно, раз он не нравится (видимо), то тогда смотрим на http://lxr.linux.no/linux+v2.6.18/include/linux/list.h и думаем, как сделать на паскале хотя бы так же и насколько страшно оно будет выглядеть. Если просто и красиво -- значит я был не прав.

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

madcore ★★★★★
()
Ответ на: комментарий от FilosofeM

Слишком толсто.

Я пытался изучать C/C++ (чисто из интереса) он сцуко тупо сложный для первого языка. Слишком долго нужно синтаксис изучать прежде чем начинать изучать собственно программирование. Но мне придётся иметь с ним дело так или иначе, я не говорю, что эти языки плохие, но мир на них не замыкается.

То, что паскаль устарел, с этим я могу и согласиться. Стоит взглянуть на python - для изучения азов самое оно. Тормознутый, правда, но для школьников, думаю, не критично.

Flaming ★★
()
Ответ на: комментарий от hobbit

> А в позднейших реализациях паскаля уже появились как обработка исключений, так и способы красиво обойтись без goto вроде всяких break/continue и exit.

Так, здесь речь про Модулу/Oberon или же про дельфи/фп (хотелось бы уточнить)?

sv75 ★★★★★
()
Ответ на: комментарий от Flaming

> Я пытался изучать C/C++ (чисто из интереса) он сцуко тупо сложный для первого языка.

ССЗБ. Изучать можно Си. А вот С++ лучше сейчас вообще не трогать.

sv75 ★★★★★
()
Ответ на: комментарий от Flaming

>То, что паскаль устарел, с этим я могу и согласиться.

тогда Linux/FreeBSD тоже устарели.

sniper21 ★★★★★
()
Ответ на: комментарий от Tu3eK

> вменяемые люди

Ещё раз: покажи мне вменяемого человека.

> когда на одной программе неправильный машинный код сгенерировался

Ты это о чём?

> в freepascal паршивая и медленная графика

Покажи замеры времени. А ещё есть uses OpenGL.

> вывод на консоль ужасно медленный

Переключись с Turbo Vision на ncurses.

> про лазарус ничего положительного сказать нельзя. ему до делфи как до луны.

Вообще-то новые фичи языка последние годы сперва появляются в FP, а затем в Дельфи :)

> не могут хотя бы отладчик довести до ума

Консольный GDB работает, отладчик в лазарусе работает, но я хочу отладчик в стиле Turbo Pascal, который на половине х86-64 систем не собирается по причине путаницы с lib-lib32-lib64. Что как положено называть по стандарту, не подскажешь?

question4 ★★★★★
()
Ответ на: комментарий от madcore

> Но по первому твоему пункту - не помню, чтобы паскаль был как-то обделен(относительно си) работой с указателями(по крайней мере в борландовских реализациях ).

Да, где-то в конце 90-ых там появилась такая же как в Си адресная арифметика. Правда, writeln(p) так и не работает (проверил в FP).

Там уже есть (очевидная) операция сложения указателя и целого числа?

> По второму тоже не понял, в чем подвох - в винегрете из макросов?

В том, как сделаны эффективные макросы.

sv75 ★★★★★
()
Ответ на: комментарий от V0ID

> Нет "хороших" или "плохих" языков. Бывают хорошие или плохие прогеры. 8))

"... и скачет не лошадь, а жокей!"

sv75 ★★★★★
()

Неплохо бы реализовать автоматический вызов деструкторов как в c++.

unkn55
()
Ответ на: комментарий от impfp

> Странный вы человек - у вас все не в порядке!

Это Тузик. Nevermind.

sv75 ★★★★★
()
Ответ на: комментарий от sv75

>Да, где-то в конце 90-ых там появилась такая же как в Си адресная арифметика. Правда, writeln(p) так и не работает (проверил в FP).

в паскале для указателей не предусмотрен вывод, можно использовать writeln(dword(p)) (fpc)

>Там уже есть (очевидная) операция сложения указателя и целого числа?

можно преобразовывать число в pointer и указатель в число и проводить операции с целыми(dword (cardinal в delphi))

unkn55
()
Ответ на: комментарий от sv75

>Да, где-то в конце 90-ых там появилась такая же как в Си адресная арифметика.

В каком таком конце? tp5 точно умел все.

>Правда, writeln(p) так и не работает (проверил в FP).


А что оно должно делать? Тебе аналог sprintf что-ли?

>Там уже есть (очевидная) операция сложения указателя и целого числа?


Думаю да, в противном случае точно было насильное преобразование типов, что-то типа (int)p + 5;

>> По второму тоже не понял, в чем подвох - в винегрете из макросов?


>В том, как сделаны эффективные макросы.


Ну да, что б си делал без препроцессора..

madcore ★★★★★
()
Ответ на: комментарий от unkn55

>>Там уже есть (очевидная) операция сложения указателя и целого числа?

> можно преобразовывать число в pointer и указатель в число и проводить операции с целыми(dword (cardinal в delphi))

Она там (в текущем FP) как есть, как я и написал выше, а это я по ошибке написал по памяти детства. Но вот p: ^^integer -- объявить всё равно не дают, как и procedure a(x: ^integer)!

sv75 ★★★★★
()
Ответ на: комментарий от madcore

>> В том, как сделаны эффективные макросы.

> Ну да, что б си делал без препроцессора..

собственно, во фрипаскале есть препроцессор в стиле С

unC0Rr ★★★★★
()
Ответ на: комментарий от madcore

> В каком таком конце? tp5 точно умел все.

Без (разумеется) явного преобразования типов? tp5 нету, а вот D5 -- точно не умеет, только что проверил. Так что и tp -- не умеет.

> Думаю да, в противном случае точно было насильное преобразование типов, что-то типа (int)p + 5;

Ага, и на 64-битной системе это враз убивает адрес :) Сейчас эта операция есть, впрочем. Ура, прогресс с 1998-го года.

> В том, как сделаны эффективные макросы.

Тут я хотел сказать "макросы для эффективных списков" :( > Ну да, что б си делал без препроцессора..

Безусловно, без него бы Си был вообще не нужен.

sv75 ★★★★★
()
Ответ на: комментарий от sv75

>> можно преобразовывать число в pointer и указатель в число и проводить операции с целыми(dword (cardinal в delphi))

>Она там (в текущем FP) как есть, как я и написал выше

Да кстати, в fpc адресная арифметика работает, а в дельфях 7 нет.

unkn55
()
Ответ на: комментарий от madcore

Как какие-нить рубипитономоноразработчики без указателей живут - уму не постижимо. Мучаются, наверное. Простейших вещей не могут.

impfp
()
Ответ на: комментарий от unkn55

> Да кстати, в fpc адресная арифметика работает, а в дельфях 7 нет.

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

Кстати, это арифметика работает и при "Delphi compatiblity mode"

sv75 ★★★★★
()
Ответ на: комментарий от impfp

> Как какие-нить рубипитономоноразработчики без указателей живут - уму не постижимо. Мучаются, наверное. Простейших вещей не могут.

В паскале нет тех механизмов, которые есть в питономоно.

sv75 ★★★★★
()
Ответ на: комментарий от impfp

> type pinteger = ^integer; procedure a(var x:pinteger);

Спасибо, я в курсе, я же не про этот изврат.

sv75 ★★★★★
()
Ответ на: комментарий от impfp

И далее, чтобы сразу предупредить вопросы в стиле int ****p[] - это тоже давно на паскале реализуемо. Тут нюанс в ином - нормальный прогер на паскале этими термами не думает. Точно так же как сишник не думает в стиле if ch in ['a'..'z'] then ...

impfp
()
Ответ на: комментарий от impfp

> Тут нюанс в ином - нормальный прогер на паскале этими термами не думает.

А что у нас в паскале для динамических матриц, хешей и прочего?

> Точно так же как сишник не думает в стиле if ch in ['a'..'z'] then ...

Так так и нормальный паскалист не думает. Потому что множества там -- недоделанные и ненужные (здесь я не в курсе про последний fp), а ещё у нас юникод на дворе. А ещё очень неясна эффективность такой конструкции, в отличите от <= and >=.

sv75 ★★★★★
()
Ответ на: комментарий от sv75

С другой стороны после питономоно я например вижу ограничения паскаля (хочу именно на паскале и именно на лазарусе) но от них не испытывается ни неудобств, ни каких ограничений. Ну, такой вот молоток - киянка... :)

impfp
()
Ответ на: комментарий от sv75

>Без (разумеется) явного преобразования типов? tp5 нету, а вот D5 -- точно не умеет, только что проверил. Так что и tp -- не умеет.

Зато строки складывать умеет :)

>> Думаю да, в противном случае точно было насильное преобразование типов, что-то типа (int)p + 5;

>Ага, и на 64-битной системе это враз убивает адрес :)


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

>Сейчас эта операция есть, впрочем. Ура, прогресс с 1998-го года.


Кто сказал, что это прогресс? :)

madcore ★★★★★
()
Ответ на: комментарий от Demon37

>Точно указатель? А не аналог ли это плюсовой передачи по ссылке?

А "плюсовая передача посслке" - не аналог ли указателя?

Led ★★★☆☆
()
Ответ на: комментарий от sv75

>ненужные - это вы, батенька, спешите хоронить :) Я лишь узрел существенный минус реализаций множеств лишь в том, что их размер ограничен. >очень неясна эффективность такой конструкци ага... if ch in ['1'..'5', 'z', 'A'] в терминах сравнений развернется куда как длиннее ;)

В свое время от замены [] на < and < я собственно почти ничего не выиграл в скорости. (была программка, обрабатывающая корпуса текстов) Перевод на Си - да, дал выигрыш. Надо стказать не настолько значительный, как хотелось бы :)

impfp
()
Ответ на: комментарий от Led

>А "плюсовая передача посслке" - не аналог ли указателя?

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

Demon37 ★★★★
()
Ответ на: комментарий от Joy_Nix

> И нах два попросту просраных года, когда это время можно отдать изучению си.

Это каким же особо одаренным надо быть, чтобы целых два года учить Си ? А вообще не язык надо учить, а алгоритмы. Язык вторичен.

Reset ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.