Форум «Всё о Паскале» _ Free Pascal, Pascal ABC и другие _ FPC 2.4.0
Автор: volvo 29.01.2010 5:01
Итак, в качестве новогоднего подарка от разработчиков FPC на официальном сайте доступна новая версия компилятора: http://freepascal.org/download.var
Изменений достаточно много:
поддержка новых платформ: 64-bit Mac OS X (x86_64/ppc64), iPhone (Mac OS X/Arm), Haiku (BeOS family), улучшенная поддержка ARM EABI;
Дельфи-подобная работа с ресурсами под всеми платформами;
улучшение генерации отладочной информации (dwarf);
общая оптимизация программы (заявляется увеличение скорости компиляции модулей)
. . .
Приведу краткий список изменений... Полный список, с объяснением их причин и методов исправления программ приведен здесь (англ. язык): http://wiki.freepascal.org/User_Changes_2.4.0
Изменения в использовании конструкций языка
1. В предыдущих версиях компилировался код, в котором константа перечислимого типа передавалась в подпрограмму:
procedure test(const a); begin end;
begin test(5); end.
, теперь он компилироваться не будет, поскольку неизвестен размер константы (1, 2, 4, или 8 байт), передаваемой в подпрограмму.
2. Свойства (properties), напрямую связанные (mapped) с полями класса, трактуются компилятором, как обычные поля класса. Если раньше можно было такие property передавать в качестве Var или Out - параметра, и получать адрес свойства, то теперь этого делать нельзя. Все property трактуются одинаково, независимо от того, связаны они с полем напрямую, или используют функции чтения/записи (getter/setter):
{$mode objfpc} type trec = record a, b: integer; end;
var c: tc; begin c:=tc.create; inc(c.myfield); // Ошибка: Нельзя получить адрес константного выражения c.rec.a:=5; // Ошибка: Аргументу нельзя присвоить значение cardinal(c.myfield):=$ffffffff; // Ошибка: Аргументу нельзя присвоить значение end.
3. Перегрузка оператора присваивания, возвращающего строку. Теперь невозможно создать такой оператор, который будет возвращать строку фиксированного размера (не равного 255). То есть, код:
type ts1 = string[4]; ts2 = string[255];
operator :=(l: longint) res: ts1; begin str(l:4,res); end;
operator :=(l: longint) res: ts2; begin str(l:20,res); end;
begin end.
компилироваться больше не будет (ts1 не является теперь допустимым типом для оператора присваивания). Если вам так уж необходимо вернуть строки разной длины - "оберните" эти строковые типы в запись:
type ts1 = record s: string[4]; end; ts2 = record s: string[255]; end;
operator :=(l: longint) res: ts1; begin str(l:4,res.s); end;
operator :=(l: longint) res: ts2; begin str(l:20,res.s); end;
begin end.
4. Описание абсолютных переменных: прежние версии FPC позволяли совмещать переменные с полями классов, элементами динамических массивов, элементами строк, и т.д. Теперь совмещение с любым разыменованным выражением запрещено. Код:
type ta = class p: pointer; procedure test; end;
procedure ta.test; var pa: ta absolute p; b: pchar; c: char absolute b[4]; begin end;
begin end.
компилироваться не будет...
5. Индексированные свойства (properties) и значения по умолчанию: если в getter-е для индексированного свойства присутствует значение по умолчанию, то при вызове можно было не указывать умалчиваемое значение Теперь этого делать нельзя, ВСЕ параметры в таких getter-ах должны быть указаны:
{$mode objfpc} {$H+}
type { TForm1 } TForm1 = class private function GetFoo(Index: Integer; Ask: Boolean = True): Integer; public property Foo[Index: Integer; Ask: Boolean]: Integer read GetFoo; end;
function TForm1.GetFoo(Index: Integer; Ask: Boolean): Integer; begin Result := Foo[Index]; // Не хватает параметра end;
end.
6. Порядок полей/методов в описании класса. Раньше можно было описывать "вперемешку" поля, свойства и методы класса. Теперь этого делать нельзя: поля должны идти перед методами и свойствами. Как результат - подобный код:
{$mode objfpc}
type tc = class constructor create; a: longint; // Поле описано после метода end;
constructor tc.create; begin end;
begin end.
компилироваться больше не будет.
7. Описания типов в списке параметров подпрограммы. Теперь нельзя конструировать тип прямо в заголовке подпрограммы, нужно предварительно описать тип (в секции Type программы/модуля), а уж потом его использовать. Так больше делать нельзя:
procedure write(var f: file of extended; e: extended); begin system.write(f,e); end;
procedure writestring(const s: string[80]); begin writeln(s); end;
function mystr: string[50]; begin mystr:='abc'; end;
Это ограничение проистекает из правила совместимости типов Паскаля: "Два типа, описанные совершенно одинаково в разных местах программы, считаются разными".
Некоторые изменения в реализации: 1. Изменены правила выравнивания переменных, имеющих тип "запись".
2. Присваивание значения True в переменную типа ByteBool/WordBool/LongBool/QWordBool теперь не эквивалентно присваиванию 1. Теперь все биты булевых переменных устанавливаются в 1 (значение становится равным "-1").
*****
Чуть позже будут выложены результаты тестирования компиляторов FPC второй ветки (2.0.0, 2.0.4, 2.2.0, 2.2.2, 2.4.0) на скорость: 1) доступа к члену класса. 2) вызова пустого статического метода. 3) вызова пустого динамического метода. 4) быстрой сортировки массива (Quick Sort). 5) пузырьковой сортировки массива(Bubble Sort) 6) "древесной" сортировки массива (Tree Sort). 7) вычисления 4500 цифр числа Пи. 8) конкатенации строк. 9) вещественных вычислений.
Автор: Lapp 29.01.2010 6:35
О_о
Однако.. Пожалуй, что рано выьрасывать предыдущую версию! Только я не совсем понял - разве п.7 не выполнялся и раньше?
Поддержка iPhone порадовала.
volvo - респект за скорость и вообще +1
Автор: volvo 29.01.2010 6:56
Цитата
разве п.7 не выполнялся и раньше?
В FPC? Нет... Вот такое свободно компилируется и выполняется в 2.2.4:
procedure p(var f: file of extended); begin write(f, 0.234); end;
var f: file of extended; begin assign(f, 'tst.dat'); rewrite(f); p(f); close(f); end.
, только что посмотрел... 2.4 это не компилирует:
Target OS: Win32 for i386 Compiling f:\programs\pascal\tt.pp tt.pp(1,25) Error: Parameters cannot contain local type definitions. Use a separate type definition in a type block. tt.pp(13) Fatal: There were 1 errors compiling module, stopping tt.pp(0) Fatal: Compilation aborted
Автор: volvo 29.01.2010 18:39
Итак, первые результаты тестов.
Для начала я решил сравнить компиляторы 2.2.4 и 2.4.0 на тесте http://math.nist.gov/scimark2/about.html, который содержит следующие тесты:
FFT - быстрое преобразование Фурье;
SOR - преобразование Якоби;
MonteCarlo - интегрирование методом Монте-Карло;
Sparse matmult - перемножение разреженных матриц;
LU — факторизация матрицы.
Все тесты проводились на одной и той же машине: Intel Core2 CPU 4400 @2GHz + 1024 Mb RAM, WinXP SP3. Настройки компиляторов: режим совместимости - Delphi, Range Checking (-), Stack Checking (+), I/O Checking (-), Integer Overflow Checking (+), генерировался быстрый код (generate faster code) для процессора Pentium4, Level 1 Optimization.
Для начала запускаем обычный тест (без ключа -large, увеличивающего размер тестируемых структур): FPC 2.2.4
Composite Score: 185.86 FFT Mflops: 34.72 (N=1024) SOR Mflops: 513.85 (100 x 100) MonteCarlo: Mflops: 20.85 Sparse matmult Mflops: 105.91 (N=100, nz=5000) LU Mflops: 253.97 (M=100, N=100)
FPC 2.4.0
Composite Score: 215.62 FFT Mflops: 35.23 (N=1024) SOR Mflops: 590.00 (100 x 100) MonteCarlo: Mflops: 16.78 Sparse matmult Mflops: 107.54 (N=100, nz=5000) LU Mflops: 328.52 (M=100, N=100)
Теперь добавляем ключ -large, и тестируем еще раз: FPC 2.2.4
Composite Score: 198.48 FFT Mflops: 22.30 (N=1048576) SOR Mflops: 500.47 (1000 x 1000) MonteCarlo: Mflops: 17.39 Sparse matmult Mflops: 149.62 (N=100000, nz=1000000) LU Mflops: 302.62 (M=1000, N=1000)
FPC 2.4.0
Composite Score: 218.14 FFT Mflops: 20.74 (N=1048576) SOR Mflops: 570.29 (1000 x 1000) MonteCarlo: Mflops: 16.78 Sparse matmult Mflops: 145.62 (N=100000, nz=1000000) LU Mflops: 337.30 (M=1000, N=1000)
Итак, на синтетическом тесте новый компилятор более эффективно работает с плавающей точкой, чем предыдущий. Если у кого есть долго выполняющаяся программа (реальная, а не синтетическая) - давайте попробуем сравнить, как скорость ее выполнения изменилась при переходе на новый компилятор
Автор: Archon 30.01.2010 12:51
Огромное спасибо за обзор, он пришелся очень кстати. Удивился, что большая часть изменений вносит в язык ограничения, а не расширяет его. В принципе, тоже нужное дело =). Очень порадовала возможность указать кодировку исходника, странно, что ты ее не упомянул. Теперь с юникодом будет куда меньше проблем.
Автор: volvo 30.01.2010 16:13
Цитата
Очень порадовала возможность указать кодировку исходника, странно, что ты ее не упомянул.
Так эта возможность появилась не в 2.4, а раньше. Теперь ее чуть-чуть подправили... Я и на 2.2.4 использовал {$codepage utf8}, вот тут, скажем: http://forum.sources.ru/index.php?showtopic=286439&view=findpost&p=2415462
Автор: SKVOZNJAK 30.01.2010 23:47
Тот форум странный, моя айпишка там забанена наверно с момента её получения и все остальные в локальной сетке тоже. Кнопка отправки сообщения администрации похоже работает только в виндовсе. А может и там не работает. Прямой ссылки на мыло в коде нет - чтобы не писали Но не очень-то и надо.
Ложь...(Показать/Скрыть)
Все прекрасно работает и под Windows, и под Debian/Gentoo, если что. Если у тебя что-то не получается - это твои личные проблемы, а перекладывать ответственность на кого-то другого - не надо. Практически у каждого админа/супермодератора/модератора на том форуме есть либо Jabber либо Skype либо ICQ. Ах ну да, это ведь тоже - только под Windows, правда? Хорошая отмазка, "у всех вокруг все неправильно, только у меня все верно". Правда, форум тоже только у тебя не работает, не это уже другой вопрос, я уверен, ты найдешь еще много других причин... Ничего, что некоторые из тех, кто занимаются форумом - вообще линуксоиды?
Новым номпилятором уже давно пользовался, успел пропатчить ИДЕ для линукса. http://freepascal.ru/forum/viewtopic.php?f=10&t=5318 Теперь лично у меня работает кодировка CP866. Когда выйдут новые версии, придётся патчить по новой - разработчики обеспечивают совместимость лишь с 437 и 850 страницами.
Автор: Romtek 22.04.2010 19:33
Так как же тогда можно с пунктом 2?
Автор: volvo 22.04.2010 19:53
Никакие трюки теперь не допускаются. Только "в лоб":
{$mode objfpc} type tc = class private fmyfield: integer; public property myfield: integer read fmyfield write fmyfield; end;
function f(X: integer): integer; begin // ... end;
var c: tc; begin c:=tc.create; c.myfield := c.myfield + 2; // Вот так - можно ... c.myfield := f(c.myfield); // И так - можно ... end.
- никаких передач свойства в качестве Var/Out параметров, операций взятия адреса, и приведения типов больше не допускается.
Цитата
Remedy: Change your code so that the address of properties is no longer taken, that they are no longer used as var or out parameters, that subscripts of properties with a non-pointer result types are no longer assigned to, and that properties to which you write are not typecasted. Note that a class instance qualifies as a pointer type in this context.
Автор: Romtek 22.04.2010 21:52
Теперь ясно. Пошли по пути увеличения строгости синтаксиса. На мой взгляд, нужно ограничивать всё, что касается адресной арифметики, потому что в работе с адресами все "чудеса" работы программ и проявляются.
Автор: SKVOZNJAK 2.05.2010 4:50
Цитата
На мой взгляд, нужно ограничивать всё, что касается адресной арифметики, потому что в работе с адресами все "чудеса" работы программ и проявляются.
"Мне бы ваши проблемы, Марь Ивановна" (с) В паскале благодаря продуманному синтаксису чудес мало. А вот сишные волшебники изобрели мегачудеса путём злоупотребления директивой #define заменяющей текст и километровым скриптам используемым вместо оператора uses. При сборке программы немного не так сгенерировался скрипт и полез в компилятор давно забытый неотлаженный код. С одной стороны даже хорошо, можно откопать живых динозавров, разве не чудо
Автор: SKVOZNJAK 24.06.2010 16:12
var B: int64; A: array[1..1000] of byte; begin B:= 2003 mod 1002; Writeln(A[B]); end.
После компиляции на старых компиляторах эта программа благополучно печатала 0, теперь error 201.
Автор: volvo 24.06.2010 17:11
Неправда, ничего не вылетает, печатается 0 как и прежде:
Эскизы прикрепленных изображений
Автор: TarasBer 24.06.2010 17:57
А в чём смысл обращаться к 1001 элементу 1000-элементнго массива? Да ещё и число 1001 так странно задано.
Автор: SKVOZNJAK 25.06.2010 20:44
Значит это только в линуксе, поленился винду загружать. Лень до хорошего не доводит http://radikal.ru/F/s60.radikal.ru/i168/1006/53/abe90128d200.jpg.html
Цитата
А в чём смысл обращаться к 1001 элементу 1000-элементнго массива?
Так компилятор не даёт явно правила нарушать, без фокусов и на ноль не поделишь. Хотя в винде может пока и не отлавливается превышение диапазона в массивах, посмотрю попозже.
Автор: Lapp 26.06.2010 10:25
Цитата(SKVOZNJAK @ 25.06.2010 17:44)
Значит это только в линуксе, поленился винду загружать. Лень до хорошего не доводит
Так компилятор не даёт явно правила нарушать, без фокусов и на ноль не поделишь. Хотя в винде может пока и не отлавливается превышение диапазона в массивах, посмотрю попозже.
может, хватит флудить в теме? SKVOZNJAK, если у тебя есть проблемы с программированием на Паскале, милости просим в раздел Задачи.
Автор: SKVOZNJAK 26.06.2010 15:55
Задачи меня почти не интересуют, так как не студент, а математика без практического применения для меня скучновата. А данный пост как раз и связан с проблемой (решённой) в программировании на FPC - нарушилась кросплатформенность исходника содержащего ошибку.
Автор: volvo 26.06.2010 20:07
Цитата
Значит это только в линуксе, поленился винду загружать.
Включение {$R+} (или -Cr) приведет к тому же результату под любой ОС...
Цитата
Хотя в винде может пока и не отлавливается превышение диапазона в массивах, посмотрю попозже.
Сделай одолжение, больше Windows не запускай никогда, ладно? Я тебе и так скажу: ловится. Уже лет 20 как... Если дать указание компилятору (казалось бы, при чем тут Windows), эту ошибку генерировать.