Автоматическое закрытие стандартного потока вывода(out

[Dry7]

Привет всем, есть вопрос -

когда (с какой версии) freepascal стал закрывать стандартных потоки ввода/вывода?

то есть когда пишешь

assign( input, 'INPUT4.TXT' );
reset( input );
assign( output, 'OUTPUT4.TXT' );
rewrite( output );

не требуется close( output ); для сохранения данных в файле?

[Attid]

сколько себя помню всегда =)
может кто из сторожил что скажет другого . . .

[Dry7]

я тоже думал что все версии закрывают, а теперь я пролетаю на городской олимпиаде по информатике только из-за того что не закрывал потоки:(((

+ очень прошу ответить тех кто знает, возможно уже в понедельник-вторник нужно будет подавать аппиляцию.

[shade]

Dry7
Незнаю как по документации, но (системный) STDIN/STDOUT закрытия не требует (и открытия тоже). Если же ты открываешь файлы, то их нужно закрывать. В учебнике по Pascal пишется, что все открытые файлы закрываются, но это не (совсем) так!

Чтобы понять стоит только откомпилировать такую вот процедуру:

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

procedure test;
var f: text;
begin
  Assign(f, 'test.txt');
  Rewrite(f);
end;


И посмотреть листинг:

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

P$PROGRAM_TEST:
; Temps allocated between ebp-592 and ebp-592
; [test.pas]
; [5] begin
      push   ebp
      mov   ebp,esp
      sub   esp,592
; Var f located at ebp-592
; [6] assign(f, 'test.txt');
      mov   edx,dword _$PROGRAM$_Ld1
      lea   eax,[ebp-592]
      call   NEAR SYSTEM_ASSIGN$TEXT$SHORTSTRING
; [7] rewrite(f);
      lea   eax,[ebp-592]
      call   NEAR SYSTEM_REWRITE$TEXT
      call   NEAR FPC_IOCHECK
; [8] end;
      leave
      ret


Как видите здесь всего 3 вызова: assign, rewrite и fpc_iocheck... никакого close нет и в помине и, я уверен, никогда не будет...

Не закрытые файлы, закрываются системой (в нормальной ОСи) при завершении процесса, но буферы, которые используют Pascal при этом уходят в небытие. Таким образом не закрывая явно файл, ты рискуешь потерять часть информации находящейся в буфере.

Что касается переменных INPUT и OUTPUT - то это обычные файловые переменные, работают по тем же правилам и по-умолчанию привязаны к STDIN/STDOUT. Если ты Assign/Reset/Rewrite на переменных INPUT/OUTPUT, то фактически они перестают быть стандартными потоками ввода-вывода.

[shade]

Хм, глянул исходники FPC 2.2 - под Windows INPUT/OUTPUT закрывается в system_exit, а вот под Linux реализация system_exit тривиальна

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

procedure System_exit;
begin
  haltproc(ExitCode);
End;


В haltproc также закрытия INPUT/OUTPUT не увидел...

+ очень прошу ответить тех кто знает, возможно уже в понедельник-вторник нужно будет подавать аппиляцию.

Подавай

Ну а вообще, файлы нужно закрывать явно, скорее всего это тебе и скажут на аппеляции...

Успех я думаю будет завесить от типа соревнования. Если было не интерактивным (т.е. решил задачки, сдал, и организаторы начинают проверять решения после соревнования), то настаивай на своем, мол задача решена правильно, а то, что компилятор их компилятор закрывает (или не закрывает) INPUT/OUTPUT ты знать не мог, т.к. они об этом явно не говорили...

Если соревнование было интерактивным (т.е. была возможность несколько раз отправить решение на автоматическую проверку и через минуту получить ответ решена/не решена), то у тебя был шанс сообразить, что ты делаешь что-то не так и понять, что именно не так. Но, всё равно, подавай на аппеляцию, т.к. ты опять же не мог знать, что там (на сервере) INPUT/OUTPUT закрывается или не закрывается...

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

[Sergei I. Gorelkin]

Если вывод ведется в стандартные потоки, то их закрывать не нужно. Мало того, в Линуксе закрытие stdin/stdout приводит к большим траблам (почитайте исходники чего угодно, везде написано большими буквами: если нужно стать демоном, перенаправь в /dev/null, но ни в коем случае не закрывай).
А если воспользовался стандартным вводом/выводом для обмена с обычными файлами (кстати, первый раз вижу, чтобы кто-то так поступал), то input и output перестают быть чем-то специальным и становятся обычными файлами, которые принято закрывать.

[Deepthroat]

А если воспользовался стандартным вводом/выводом для обмена с обычными файлами (кстати, первый раз вижу, чтобы кто-то так поступал)

Я такое видел только в официальных решениях задач с олимпиад... По-моему, тупость какая-то. Сначала учат такой фигне, а потом еще чего-то хотят.

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

[shade]

А если воспользовался стандартным вводом/выводом для обмена с обычными файлами (кстати, первый раз вижу, чтобы кто-то так поступал), то input и output перестают быть чем-то специальным и становятся обычными файлами, которые принято закрывать.

На олимпиадах так делают очень часто - отлаживать решения проще. Сначала дебагишь на консоле, а перед отправкой решения раскомментриуешь {assign/reset/rewrite} и отправляешь решение. Сам всегда так делал на олимпиадах, но при этом не забывал делать close

[Deepthroat]

Надо баллы за такое снимать. Хотя, олимпиада олимпиаде рознь: одно дело алгоритмизация, другое - реализация. Если задача олимпиады выявить лучшего по составлению алгоритмов, то и нефиг за отсутствие close штрафовать. А если на олимпиаде важна реализация, а алгоритм вторичен (естественно, программа должна работать), то штрафовать надо за переназначение.

Все это IMHO, конечно, но зачем детей извращениям учить? Как говорит один мой знакомый, "надо делать хорошо, плохо - само получится".