Действительно добавляем в @Mark Harrison ...
Люди, которые говорят вам, что Unix «просто выводит текст, указанный программистом», а DOS не работает, совершенно не правы. Также утверждается, что для DOS глупо помечать EOF, когда он видит символ EOF, что ставит вопрос о том, для чего конкретно этот символ EOF.
Не существует единого истинного соглашения для окончаний строк текстового файла - только соглашения для конкретной платформы. В конце концов, даже CR-LF, CR и LF не единственные соглашения о конце строки, которые когда-либо использовались, и ASCII никогда не был даже единственным и единственным набором символов. Проблема заключается в стандартной библиотеке C и среде выполнения, которая не отвлекает эту деталь, зависящую от платформы. Другие языки третьего поколения (такие как Pascal и даже Basic) справились с этим, по крайней мере, до некоторой степени. Из-за этого, когда компиляторы C были написаны для других платформ, для достижения совместимости с существующим исходным кодом и книгами были необходимы хаки библиотек времени выполнения.
Фактически, именно Unix и Multics первоначально нуждались в переводе строк для консольного ввода-вывода, поскольку пользователи обычно сидели за терминалом ASCII, который требовал завершения строки CR LF. Этот перевод был выполнен в драйвере устройства, однако цель состояла в том, чтобы абстрагироваться от особенностей устройства, предполагая, что было бы лучше принять одно соглашение и придерживаться его для сохраненных текстовых файлов.
Хакерство ввода / вывода на С текст в принципе похоже на то, что делает сейчас CygWin, взламывая среды выполнения Linux, чтобы работать так же, как и можно ожидать в Windows. Есть реальная история взлома, которая превращает их в Unix-подобные, но есть и Wine, превращающий Linux в Windows. Как ни странно, вы можете прочитать неуместную критику Windows в конце строки в CygWin FAQ (ссылка на Интернет-архив добавлена в 2013 году - страница больше не существует). Может быть, это просто чувство юмора, поскольку они в основном делают то, что критикуют, но в гораздо более широком масштабе; -)
Стандартная библиотека C ++ (на какой бы платформе она не реализована) устраняет эту проблему, используя iostreams, которые абстрагируют от конца строки. Для вывода это мне подходит. Для ввода мне нужно больше контроля, поэтому я либо интерпретирую посимвольные символы, либо использую генератор сканера.
[ РЕДАКТИРОВАТЬ Оказывается, что зачеркнутое утверждение выше не соответствует действительности и никогда не было. std::endl буквально переводится как \n и флеш. \n - это то же самое, что \n, которое вы получаете в C - его обычно называют «новой строкой», но на самом деле это символ перевода строки ASCII, который затем переводится средой выполнения при необходимости. Забавно, что ложные предположения могут быть настолько укоренившимися, что вы никогда не подвергаете их сомнению - в основном, у C ++ не было выбора делать то, что делал C (кроме добавления большего количества слоев сверху) по причинам совместимости, и это всегда должно было быть очевидным.]
Самая большая доля вины от моего POV связана с C, но C не единственный проект, который не может ожидать его перехода на другие платформы. Обвинять Билла Гейтса - просто чокнутый - все, что он делал, это покупал и полировал вариант тогдашнего популярного CP / M. На самом деле, это просто история - та же самая причина, по которой мы не знаем, какие коды символов от 128 до 255 относятся к большинству текстовых файлов. Учитывая простоту совмещения со всеми тремя соглашениями о конце строки, странно, что некоторые разработчики все еще настаивают на том, что «соглашение о моих платформах - единственный верный путь, и я навязываю его вам, нравится вам это или нет».
Также - заменит ли кодовая точка Unicode U + 2028 все эти условные обозначения в будущих текстовых файлах? ; -)