Историческая причина того, что разные линии заканчиваются на разных платформах

DOS унаследовал окончания строк CR-LF (то, что вы называете \ r \ n, просто делая символы ascii явными) от CP / M. CP / M унаследовал его от различных операционных систем DEC, которые повлияли на дизайнера CP / M Гэри Килдалла.

CR-LF использовался для того, чтобы телетайпы возвращали печатающую головку к левому краю (CR = возврат каретки), а затем переходили к следующей строке (LF = перевод строки).

Ребята из Unix обрабатывали это в драйвере устройства и при необходимости переводили LF в CR-LF при выводе на устройства, которые в этом нуждались.

Как вы уже догадались, Mac OS X теперь использует LF.

Действительно добавление к @Mark Harrison ...

Люди, которые говорят вам, что Unix «просто выводит текст, указанный программистом», в то время как DOS не работает, совершенно неправы. Также есть утверждения, что со стороны DOS глупо отмечать EOF, когда она видит символ EOF, что поднимает вопрос о том, для чего именно этот символ EOF.

Не существует единого истинного соглашения для окончаний строк текстового файла - только соглашения, специфичные для платформы. В конце концов, даже CR-LF, CR и LF - не единственные используемые соглашения о конце строки, а ASCII никогда не был даже единственным набором символов. Проблема заключается в стандартной библиотеке C и среде выполнения, которые не абстрагировались от этой платформо-зависимой детали. Другим языкам третьего поколения (например, Pascal и даже Basic) это удалось, по крайней мере, до некоторой степени. Из-за этого, когда компиляторы C были написаны для других платформ, для достижения совместимости с существующим исходным кодом и книгами потребовались взломы библиотеки времени выполнения.

Фактически, именно Unix и Multics изначально нуждались в переводе строк для консольного ввода-вывода, поскольку пользователи обычно сидели за ASCII-терминалом, который требовал окончания строки CR LF. Однако этот перевод был выполнен в драйвере устройства - цель заключалась в том, чтобы абстрагироваться от специфики устройства, предполагая, что было бы лучше принять одно соглашение и придерживаться его для сохраненных текстовых файлов.

Взлом текстового ввода-вывода C в принципе аналогичен тому, что делает сейчас CygWin, взламывая среду выполнения Linux, чтобы она работала так же хорошо, как и следовало ожидать в Windows. Есть реальная история взлома вещей, которые собираются превратить их в Unix-подобные, но есть еще Wine, превращающий Linux в Windows. Как ни странно, вы можете прочитать некоторую неуместную критику Windows в конце строки в CygWin FAQ (ссылка на Интернет-архив добавлена ​​в 2013 году - страница больше не существует). Может быть, это просто их чувство юмора, поскольку они в основном делают то, что критикуют, но в гораздо большем масштабе ;-)

Стандартная библиотека C++ (на какой бы платформе она ни была реализована) позволяет избежать этой проблемы с помощью iostreams, которые абстрагируют концы строки. Для вывода меня это устраивает. Для ввода мне нужно больше контроля, поэтому я либо интерпретирую посимвольно, либо использую генератор сканера.

[РЕДАКТИРОВАТЬ Оказывается, вычеркнутое утверждение выше неверно и никогда не было. std::endl буквально переводится как \n и флеш. \n - это точно такой же \n, что и в C - его обычно называют «новой строкой», но на самом деле это символ перевода строки ASCII, который затем при необходимости переводится средой выполнения. Забавно, как ложные предположения могут настолько укорениться, что вы никогда не ставите их под сомнение - в основном, у C++ не было выбора делать то, что сделал C (кроме добавления дополнительных слоев поверх) по причинам совместимости, и это всегда должно было быть очевидным.

Самая большая часть вины с моей точки зрения связана с C, но C - не единственный проект, который не смог предвидеть свой переход на другие платформы. Обвинять Билла Гейтса - безумие - все, что он сделал, это купил и отшлифовал вариант популярного тогда CP / M. На самом деле, это просто история - по той же причине, по которой мы не знаем, какие коды символов от 128 до 255 относятся к большинству текстовых файлов. Учитывая легкость совладания со всеми тремя соглашениями о конце строки, странно, что некоторые разработчики до сих пор настаивают на том, что «мое соглашение о платформах - единственный верный путь, и я навяжу его вам, нравится вам это или нет».

Кроме того, заменит ли код разделителя строк Unicode U + 2028 все эти соглашения в будущих текстовых файлах? ;-)

Интересно отметить, что CRLF в значительной степени является интернет-стандартом. То есть почти каждый стандартный интернет-протокол, ориентированный на линию, использует CRLF. SMTP, POP, IMAP, NNTP и т. д. Тело электронного письма состоит из строк, заканчивающихся CRLF.

Согласно Википедии: вначале программа должна была ввести дополнительные символы CR перед LF, чтобы замедлить работу программы, чтобы у принтера было время, чтобы не отставать - и CP / M, а затем Windows использовали этот метод. Но драйвер принтера Multics автоматически вводил дополнительные символы, так что программе не нужно было этого делать - и разработчик Unix от этого. Но ничто из этого не объясняет, почему ранние Mac этого не делали (теперь они это делают, поскольку они основаны на Unix).

https://en.wikipedia.org/wiki/Newline#History:

The sequence CR+LF was commonly used on many early computer systems that had adopted Teletype machines—typically a Teletype Model 33 ASR—as a console device, because this sequence was required to position those printers at the start of a new line. The separation of newline into two functions concealed the fact that the print head could not return from the far right to the beginning of the next line in time to print the next character. Any character printed after a CR would often print as a smudge in the middle of the page while the print head was still moving the carriage back to the first position. "The solution was to make the newline two characters: CR to move the carriage to column one, and LF to move the paper up."[1] In fact, it was often necessary to send extra characters—extraneous CRs or NULs—which are ignored but give the print head time to move to the left margin. Many early video displays also required multiple character times to scroll the display.

On such systems, applications had to talk directly to the Teletype machine and follow its conventions since the concept of device drivers hiding such hardware details from the application was not yet well developed. Therefore, text was routinely composed to satisfy the needs of Teletype machines. Most minicomputer systems from DEC used this convention. CP/M also used it in order to print on the same terminals that minicomputers used. From there MS-DOS (1981) adopted CP/M's CR+LF in order to be compatible, and this convention was inherited by Microsoft's later Windows operating system.

The Multics operating system began development in 1964 and used LF alone as its newline. Multics used a device driver to translate this character to whatever sequence a printer needed (including extra padding characters), and the single byte was more convenient for programming. What seems like a more obvious[citation needed] choice—CR—was not used, as CR provided the useful function of overprinting one line with another to create boldface and strikethrough effects. Perhaps more importantly, the use of LF alone as a line terminator had already been incorporated into drafts of the eventual ISO/IEC 646 standard. Unix followed the Multics practice, and later Unix-like systems followed Unix. This created conflicts between Windows and Unix-like OSes, whereby files composed on one OS cannot be properly formatted or interpreted by another OS (for example a UNIX shell script written in a Windows text editor like Notepad).