Форум Всеукраїнської інтернет-олімпіади NetOI

Вопрос раз: речь идет о домашнем Паскале или о сообщении серверного компилятора?

я полагаю, не косого паскаля нету и сам пишу на c++

Grivus:
Могу предположить лишь следующие варианты, это не панацея, а скорее попытка разбирательства...
Во-первых, пробежавшись по freepascal.org, я увидел, что подобная ошибка была замечена у некоторых на FPC 2.0.4 и решалась после обновления. Если у тебя до сих пор предыдущая версия, советую скачать 2.2.0.
Во-вторых, чаще всего эта ошибка наблюдалась при использовании кода на ассемблере... Ты уверен, что никаких подобных хакерских методов не юзаешь?
В-третьих, если не поможет, попробуй использовать компилятор командной строки. В папке bin лежит файл fpc.exe. Если набрать в командной строке <путь к файлу fpc.exe> <исходник, который нужно скомпилировать>, то по идее происходит простая компиляция без запуска среды разработки. На досуге ещё почитай различные опции его использования (для этого просто запусти в командной строке fpc без параметров).

Silicious Man написав:

я полагаю, не косого паскаля нету и сам пишу на c++

Не косого паскаля? Нету. Согласен. Не косого языка паскаль-группы? Есть. Имя ему Delphi. И последние 2 года для написания олимпиады использую только его

guest1 написав:

И еще, откуда у тебя код ошибки 0, если исходник даже не компилируется?
Код ошибки вроде должен быть инициализирован после начала выполнения.

У него не код ошибки 0 Было сказано, что "попробовал поискать по коду ошибки, результат - ноль" (то есть не нашёл).

guest1 написав:

если arr - массив, тогда строка типа:
for arr[1]:=1 to 9 do ...
не прокатит.

Интересно. У меня без проблем компилируется и работает...

Відредаговано Skiminok (2008-01-06 18:59:13)

guest1 написав:

Вспомнил случай, когда я делал генератор исходника, и у меня получалось такое:
var s: ansistring;
begin s:=''+
'<строка 124 символа>'+
'<строка 124 символа>'+
... много таких строчек и в конце точка с запятой.
Так если строчек было слишком много, выходил Internal Error и, кроме того, вылетал сам Free Pascal с ошибкой. И, кроме того, временно появлялись странные полосы на экране, с чем связано, не знаю

Ну это раньше в FPC было... переполнение памяти при работе со строками. По-дурному реализовано было. Сейчас вроде бы исправили, хотя гарантии не дам.

guest1 написав:

а, вспомнил, извиняюсь.
for arr[1]:=1 to 9 do ...
работать будет, а вот
for arr[1]:=1 to 9 do
    for arr[2]:=1 to 9 do...
не будет.

Ну, это логично... FPC мало того что (абсолютно правильно) запрещает присваивание счётчику цикла For, так ещё и учитывает при этом управляющей переменной почему-то не arr[1], a arr... с последующими ругательствами, что счётчик цикла arr потом нельзя уже как-то изменять...
Можно считерить... включить в первых строчках программы {$mode TP}. Всего-то изменится несколько установок компилятора - то бишь синтаксиса. А проблема исчезнет

guest1 написав:

Неужели так сложно было реализовать возможность создания этого в for?

Skiminok написав:

... абсолютно правильно запрещает присваивание ...

Неправильно это. Несправедливо то бишь

Ха. А зачем и почему вообще появился цикл for, если на самом деле он спокойно реализуется while'ом? А именно потому что на процессорном уровне он реализовывается гораздо быстрее. Только вот с управляющей переменной вечные траблы. Именно на том же внутреннем уровне. Главный аргумент - строчка в документации Делфи (в документации FPC я подобное на нашёл, к сожалению):

For-loop control variable may be undefined after loop.

Реализация не та. Что у тебя произойдёт, если ты изменишь в цикле его управляющую переменную или верхнюю границу? Обычно кирдык. Попробуй в Турбо написать такое:

var i,N: integer;
begin
  N:=5;
  for i:=1 to N do
  begin
    If i<4 then Inc(N);
    Write(i,' ');
  end;
end.

Получим четырёхкратно выполнившийся полный цикл от 1 до 5, хотя ожидалось не совсем то
А если разрешить изменение контрольной переменной - тогда все преимущества скорости For летят в тартарары...

Его нельзя назвать кривым. Он просто реализован с учётом наилучшей оптимизации, а не логики человека. И, как по мне, с этой стороны - превосходно. Со стороны удобства программиста - вопрос спорный...
Нет, я согласен, что сишный for - вообще вещь, не имеющая аналогов Но тут проблема появляется в другом. С таким for-ом, наоборот, while'a не надо - нарушаются традиции истории развития программирования. Всё-таки циклы принципиально разные, и появился второй (for) позже, когда потребовалось аппаратное ускорение именно отдельного класса задач - перебор в заданных рамках. А превращать for в машину, которая разве что кофе не варит - это надругательство над теорией информатики...

Версия у меня 2.2.0,
Ты уверен, что никаких подобных хакерских методов не юзаешь?

Да нет, наверное) но я ещё погляжу)

Турбо? Согласен, тут можно чего угодно ожидать. Посты выше это показали.
Учитывая, что изменение контрольной переменной цикла турбик без проблем позволяет и никакой оптимизации по факту не делает... то там полнейший бред выходит.
А вот по поводу FPC у меня совершенно другие результаты измерений получились...

Не трогай всех директив. Напиши только те, которые нужны тебе конкретно. Обычно кроме R, N и H олимпийцу на Фри Паскале ничего для счастья не надо...
Просто в первой строчке программы (не трогая директив, не прикасаясь к Ctrl+O+O):
{$R+,N+,H+}
(это к примеру, на самом деле определись, что тебе из них точно нужно... потому как включённый R+, например, заметно тормозит прогу, в то время как в процессе дебага он незаменим).

А какой уровень оптимизации был включён?

Grivus написав:

Хм, ну вообщем проблема стандартная: под Turbo всё работает, а под Free даже не компилится. Пишет Internal error 200309201 в строке, где end; завершает функцию. Искать по коду ошибки пробовал, 0. Что бы это могло значить? (вариант косые руки не предлагать пожалуйста:) )

Бывало иногда. Перепиши код. Может вырезать-вставить покатит. Не знаю. Помню только, что что-то делал с кодом или... перезапустил ФП!