FPC 3.0 RC1 announced

[Kitayets]

Не знаю, как на сайте новость добавить, так что пишу здесь,

Вчера, 25 Августа 2015, разработчики объявили о выходе первого кандидата в релиз (Release candiaate 1) компилятора free pascal версии 3.0.

Все заинтересованные пользователи приглашаются к тестированию.

Информация о том как сообщить замечания - http://wiki.freepascal.org/Testers_3.0.0

Новые функции версии 3.0 - http://wiki.freepascal.org/FPC_New_Features_3.0

Изменения, которые могут потребовать переработки кода - http://wiki.freepascal.org/User_Changes_3.0

ссылка на сам анонс - http://forum.lazarus.freepascal.org/index.php/topic,29457.msg186072/topicseen.html?PHPSESSID=c6d6f2f8dcecc41763a98d55be63ff93#new

[Vadim]

Ну, теперь всё! Тут то мы и попрыгаем...

[Cheb]

Оченно рад. Выглядит так, что мне теперь не придётся портировать свои страшные ктулхаки в обработке исключений с Win32 на Win64.

Добавлено спустя 4 часа 3 минуты 53 секунды:
Страница для тестеров пока - пустая затычка. Повествую здесь.


Ужос №1. Первый раз компиляция заканчивается нормальной ошибкой (попутно подчищаю сопли с AnsiString). Повторный запуск - компилятор делает хряп, пока не удалишь все PPU.
Кровавые подробности, выданные -vv :
00008000:Searching file chelinfo.pp... found
10010000:chelinfo.pp(244,16) ENDIF DARWIN found
10000001:Fatal: Compilation aborted
Причём, за это самое "ENDIF DARWIN" он почему-то принимает точку с запятой (пробовал двигать - всегда указывает точно на после неё). Реальный эндиф - глубоко в хвосте юнита.
Хакнул вокруг, добавив в батник неэлегантное
del /Q ......tmpmain*.ppu
del /Q ......tmpmain*.o

P.S. Добавка/удаление -XX влияет на то, сколько юнитов скомпилирует прежде, чем хряпнуться.

Добавлено спустя 5 минут 22 секунды:
Использовал TStringList чтобы программа в рантайме обновила кусок собственных исходников, высрав кучу строк в utf-8 (никак руки не дойдут избавиться от моего старого фтагна многоязычности).
То, что работало раньше, с радостью запороло текст, высрав его в ANSI.
Заменил

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

sl.Add('    ''' + Utf8Encode(ws) + ''',');

на

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

sl.Add(Utf8Encode('    ''' + ws + ''',')); 

, где ws - UnicodeString,
и сразу заработало.

Добавлено спустя 57 минут 42 секунды:
Экзешник собрался, запустился, всё пучком.
На DLL игрового модуля компилятор хряпнулся с D:\chentrah\modules\chentrah\src\mo_cps_scenario.inc(270,3) Fatal: Internal error 200309041

Причём, в fpcdebug.txt выдал всё то же ENDIF DARWIN found в том же многострадальном chelinfo.

Буду завтра вечером шаманить, что ему надо.

[hinst]

из новых фич я вижу только одну фичу: codepage-aware-strings, и эта фича - гавно

[Cheb]

В теории, надо было вводить новый ключ, вроде {$longstrings, по умолчанию выключенный. И новую строку называть как-то по другому, не трогая не AnsiString.

Фича отличная, и обязательно засияет -- после того, как соберёшь мягким местом все занозы от перехода на неё.

[hinst]

Нифига, фича гавно. С такими фичами я бы предпочёл чтобы они в самом деле успокоились и не делали новые фичи вообще. Единственная нормальная фича это когда внутри вся стандартная библиотека языка использует одну кодировку и вся программа на этом языке использует эту кодировку. В Java и Delphi это Unicode. В Go и FreePascal это UTF-8. Перекодировка должна происходить только при записи в файлы или при отправке данных по сети. Но затем в FreePascal чё-т передумали и решили прицепить кодировку к string

1. В других языках программирования так не сделали, а сделали определённую стандартную кодировку
2. До этого всё прекрасно работало и так. Не работало только у тех, кто не знает что такое кодировка.
3. Оверхэд по перформансу! тормозит1! теперь на каждый чих и на каждый s := s + '.' будет проверяться кодировка

[sts]

эээ а где написано про каждый чих? и зачем проверять?

Добавлено спустя 1 минуту 48 секунд:
в jave строки тоже с кодировкой и никаких автоматических конвертация нету, делают сами, там где надо.

Добавлено спустя 7 минут 15 секунд:
зато, можно сделать автоматическую конвертацию при конкатенации строк типа UnicodeString1:= UnicodeString2 + AnsiString2 и это хорошо, но везде проверку пихать - нету смысла.

[Kitayets]

2hinst

эээ codepage-aware-strings - это ж прямая калька с новых версий delphi.... они там их едят и не жужжат. Проблема только, когда все толстые библиотеки (особенно LCL) смогут корректно эти строки переваривать не портя кодировки.

[hinst]

В Delphi кодировка двухбайтовый Unicode и кодировка строго определённая. Стандарт для дельфи это Unicode. Да, для AnsiString есть фича которая присоединяет к AnsiString, но это совсем другая фича которая во-первых жопная, а во-вторых это не кодировка а локаль; а втретьих она не должна использоваться вообще ведь стандартная библиотека Delphi, включая VCL работают в Unicode и кодировка фиксированная Unicode

[kazalex]

которая во-первых жопная, а во-вторых это не кодировка а локаль

Во-первых, фича не жопная, а весьма удобная. И очень жаль, что её выпилили из мобильных компиляторов (кстати, запрос на возвращение таких строк в мобильные компиляторы один из самых голосуемых на QC). Во-вторых, локаль это более широкое понятие включающее как набор символов так и другие региональные особенности, а в AnsiString указывается именно кодировка, а точнее кодовая страница.

а втретьих она не должна использоваться вообще ведь стандартная библиотека Delphi, включая VCL работают в Unicode и кодировка фиксированная Unicode

Почему не использовать, если это удобно? Конвертирование таких строк в юникод делается автоматически, поэтому никаких проблем с их использованием в юникодных RTL и VCL нет.

[Mikhail]

зато, можно сделать автоматическую конвертацию при конкатенации строк типа UnicodeString1:= UnicodeString2 + AnsiString2 и это хорошо, но везде проверку пихать - нету смысла.

Зачем? Все эти неявные преобразования создают проблем больше, чем решают. Надо отставить два встроенных типа строк Юникод и однобайтовые AnsiString, без указания кодировок. Все преобразования типов строк только явно!

[kazalex]

Все эти неявные преобразования создают проблем больше, чем решают

Расскажи какие проблемы они создали лично тебе.

Все преобразования типов строк только явно!

На неявное преобразование строк (в обе стороны) компилятор даёт предупреждение. После чего ты делаешь преобразование через кастинг и вот у тебя уже явное преобразование. Аллилуйя!

[Mikhail]

Расскажи какие проблемы они создали лично тебе.

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

[kazalex]

Например перекодировка, когда это не нужно.

Очевидно, что если нет нужды в преобразовании, то и использовать различные типы строк не нужно.

Кроме того это ведет к созданию неэффективного кода и увеличивает размер программы.

Если же преобразование требуется, то его придётся делать тем или иным способом, и это однозначно увеличит размер программы (использование дженериков увеличивает его значительно больше, но дженерикам все рады).

Никакой нужды в постоянной перекодировке строк, как правило, нет. А если это все-таки нужно, то это делается по месту и явно

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

[runewalsh]

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

В делфи-варианте любая операция со строкой — потенциальное преобразование, о том и речь. Я надеюсь, это отключаемо?