Оно ещё живо? Помянем вставая.

PS: видел в последний раз Pascal как Turbo-Pascal в начале 90-х.

А они новые фичи языка тоже делают

Это когда каждые три года надо переучивать язык? Или вы о чём-то другом?

Я в пруфы на отсутствие (нужности/востребованности новых Дельфи) не умею (а то Рассел чайником побьет), поэтому только газификация.

А по твоей ссылке каноничные 220 миллиардов строк кода на Коболе - http://skeptics.stackexchange.com/q/5114

оберон

Фуууу. Брось каку.

Строки типа AnsiString теперь хранят информацию о своей кодировке.

Пугали что будет портить в строках некондиционную информацию, но вроде пока этого не делает. Или я в тесте

var
ZZ: byte;
A,B: ansistring;

begin
A:=#0#1#2#255;
B:='Ананимус жрёт чеснок ';
B:=B+A;
B:=B+#49#50#51;
for ZZ:=1 to length(B) do Writeln(ord(B[ZZ]));
Writeln(B);
end.

Добавлена поддержка следующих целей:

MS-DOS real mode.

RPM для установки в досе http://sourceforge.net/projects/freepascal/files/Linux/3.0.0/RPM/ это сильно:)

как с кириллицей в fp (IDE)?

В 2.6.4 было нормально. Последний пункт - экспериментальный. Идёшь на страницу проекта с переводами, находишь ссылку на «репозиторий» на народе, качаешь патчи, правишь исходники и компиляешь себе ИДЕ с переводом и поддержкой правильных кодировок. По мере необходимости появляются улучшенные версии наборов патчей. Вот мне, как линуксоиду, нравится кодировка UTF-8_Ru-extra

А -О3 заработал уже? А генерил неработоспособный код.

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

Компилятор точно не знаю, но написаны yf object Pascal

берём LGPL header-only библиотеку на C++, линкуем статически (в общем-то по другому и не сделать)

Каша в голове. Вы точно понимаете, что такое компоновка? Вы просто напрямую включите исходный код библиотеки в код своей программы.

Гуд.

А этот компилятор годится для замены компилятора Delphi?

Оно шевелится!

см. Lazarus

Улучшения совместимости с Delphi:

Изменения в компиляторе:

Трололо, совместимость с некроделфями на первом месте. ТС намекает, что сабж ненужно?

Компиляция не нужна) дипеляция тоже)) только хардкор, только интерпретация) и будет всем счастье) и fsf будет не нужно. Хотя оно и так не нужно))

А есть хорошие книжки по Паскалю на русском?

Злая проприетарщина без будущего же. Каждый следующий релиз дороже и глючнее чем предыдущий. Число юзеров неуклонно падает.

Уже упало до трех миллионов. На 2млн с 1991 года. Скоро капец.

А есть хорошие книжки по Паскалю на русском?

Из древнеклассических: Вирт, остальное тут.

есть какие-то сложности с вливанием изменений в апстрим, не знаешь?

MSE IDE/MSE GUI

Кстати, за пару недель до выхода FPC3 (13 ноября) вышла ориентированная на эту версию фри-паскаля версия 4.0 альтернативной лазарусу RAD http://msegui.com/ (отличающаяся легковесностью, своего рода аналог KOL/MCK если кто такую вещь помнит). Среда, в отличии от Лазаря с дельфями несовместима, и да, вся графика отрисовывается самостоятельно, ни Gtk, ни Qt не используется, только иксы (под виндой, естественно, GDI)

Конечно есть. Там же только русский язык приделан а не все неанглийские сразу - апстрим такое не примет. А чтобы приделать кучу нерусских языков, нужно лепить какую-то многобайтовую кодировку которая их потянет одновременно, то есть проделать ещё много работы по реверсинжинирингу кода с ООП покусанным сями. А просто русский язык с кодировками IBM866 и русскими буквами из UTF-8 приделывается довольно просто, даже смешивать их можно. Есть там в редакторе труднообнаруживаемый баг, который при каком-то событии портит отображение русских букв, но он затыкается обновлением экрана, которое нужно делать пореже, чтобы не грузить проц на каждый чих. Патчи попроще и «интернациональные» в апстрим вливались более-менее, хоть и не всегда быстро.

Лёгкие и действительно вредные баги редактора давно исправлены, осталась трудоёмкая мелочь за которую никто не хочет браться. Сборку в линуксе с GDB поновее в апстрим не пропихнёшь, но актуальность этого скоро должна пропасть - в транке с середины марта, в версии 3.1.1, можно собирать с динамической линковкой отладчика командой make all GDBMI=1 NOGDB=1 Если опять не забудут положить обновление в релиз. Но вполне возможно, что в официальном пакете будет собрано по старинке и со старым отладчиком:)

Хотя, можно попробовать расширить экспериментальный режим кодировок на рисовку утф-8 большего количества, желательно всех что потянет ОС, символов со стрелочками спереди и заузить :( для остальных. Если канал с ";«№;%::??№ указателями пропустит такую информацию, точно не помню. Тогда можно троллить апстрим конкретно:)

Есть такие книжки

Есть такие книжки по Turbo Pascal под авторством Фаронова. По особенностям Free Pascal такого я не знаю.

Лично я mse не осили, вроде почти все есть, но как-то неочевидно и через ж. Лазарь кошернее.

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

Ну да, логика у MSE другая несколько. Ну что ещё можно о нём сказать — changelog не привожу, автор его ведёт достаточно небрежно, а сам я плотно за проектом не слежу. Где-то он писал, что улучшена работа со скинами и базами данных… Ну и да, кодировка (внутри GUI) поменялась с UCS2 на более универсальную UTF-16. Да, кроме FPC3, MSE нормально собирается с 2.6.4 (что с учётом релиза до FPC3 воообще-то логично)

она уже давно есть

Pascal.ABC.Net

Ну, а всё таки, чем оно лучше FreePascal/Lazarus (ну или того же MSE, хотя ладно, с последним всё ясно, немейнстримово и интерфейс школьника/первокурсника может слегка испугать) с точки зрения обучения основам?

end.

.NET
MS DOS

Вы же не серьёзно?

А есть хорошие книжки по Паскалю на русском?

По турбопаскалю - куча. Есть также замечательная книжка 1998 года «Боон К. Паскаль для всех», основные принципы языка изложены чисто и конкретно. Про объект-паскаль пишут и сейчас. Дельфийские справочники во многом подходят.

Там гото нет - очередное обероностроительство.

Если же писать слишком длинные заумные формулы

Не длинные и не заумные. Циклы, циклы, циклы.. Численное интегрирование и решение дифуров. Без оптимизации ОК, с О3 лажа и ексепшены.

Ну и обработка GUI-шных событий лажует.

Численное интегрирование и решение дифуров. Без оптимизации ОК, с О3 лажа и ексепшены.

Можете предоставить минимальный воспроизводимый тестовый пример?
Спасибо заранее.

тем, что создавалось специально для обучения.

чего-то недописал?

Нет преобразований кодировок WideString <-> AnsiString.

Не длинные и не заумные. Циклы, циклы, циклы..

Использую в них гото почти по максимуму и О3 им не мешает. Если используешь гото, то про циклы кроме фор даже помнишь смутно: есть такие, когда-то писал.

Тогда всё в порядке - WideString не такая важная системная фича как AnsiString, в среднестатистическом хелловорде их можно вообще не применять. А те что под капотом, пусть обрабатываются как угодно, лишь бы не тормозили.

С AnsiString тоже можно вызывать косяков. Только для этого придётся хранить данные в разных кодировках. Кодировку можно задать при объявлении

CP866String = type AnsiString(866);

или на лету через SetCodePage(). Тогда при присвоении строк тоже выполняется скрытое преобразование. Оно же используется в функциях обработки строк, типа Length() или AnsiUpperCase(). При преобразовании в несовместимые кодировки недопустимые символы могут заменяться на заглушку (обычно "?"). Корректная работа вообще возможна при загруженном менеджере строк. В венде используется системные API без лишних телодвижений. Для Unix pure pascal модуль ещё не написан и надо подключать cwstring.

С AnsiString тоже можно вызывать косяков. Только для этого придётся хранить данные в разных кодировках. Кодировку можно задать при объявлении

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

Если используешь гото, то про циклы кроме фор даже помнишь смутно: есть такие, когда-то писал.

Похоже что -О3 ориентирован на GOTO. В других случаех весьма ненадежно. Жди беды.
В общем, я для себя решил никогда не использовать -О3. Пусть тормозит -О1, но предсказуемо тормозит.

А если тип кодировки и кодой страницы нигде не объявлять?

По умолчанию системная берётся. Для русской венды через API будет 1251 использовано. Для unix - utf8 скорее всего.

Но для unix надо обязательно в начало программы cwstring добавлять. Потому что без этого в unix даже ansiuppercase не будет нормально работать, потому что внутри она так реализована:

function AnsiUpperCase(const s: string): string;
begin
    result:=widestringmanager.UpperAnsiStringProc(s);
end;

Размеется, там ansi версия используется, без преобразования в unicode. Просто таблицы сравнения и регистра для разных кодировок сложны и free pascal делегирует их пока во вне.

В венде хватает API, в unix будет зависимость от iconv. Если этот модуль не подключен, то за пределами венды кодировка будет полагаться ISO 8859-1.

Бред какой-то. А можно задать нулевую кодировку или заведомо несуществующую, чтобы текст в ансистрингах не портили?

«Нулевая кодировка» есть, тип RawByteString, определён как раз как

RawByteString = type AnsiString(CP_NONE)

В остальных вариантах надо использовать string и не дёргаться. Потому что они ничего не портят. Они как раз делают то, что надо. У вас раньше фактически все AnsiString в старых Delphi (до 2009) или старых Free Pascal были строками с текущей локалью. Теперь просто можно написать многоязычную ansi программу, которая бы поддерживала более двух языков, один из которых английский. Ну или unicode-программу, которая бы могла читать/писать в ansi в разных кодировках и всё это минимальными усилиями.

Для тех, кому это не нужно - просто продолжают использовать string и вообще ни о чём не беспокоятся.