最近我正在使用一些字符串，文本输入，类似的东西，我意识到我对2个字符 - LF（10）和CR（13）有点困惑。每次我需要开始新行时，我都使用std :: endl作为c ++字符串，\ n \ n \ n对于c-strings使用LF。但是我现在正在使用一个库，它在返回时按键发送给我的不是LF而是CR键代码。我在维基百科上看到用法如下：
CR+LF: Microsoft Windows, DEC TOPS-10, RT-11 and most other early non-Unix and non-IBM OSes, CP/M, MP/M, DOS (MS-DOS, PC-DOS, etc.), Atari TOS, OS/2, Symbian OS, Palm OS
LF+CR: Acorn BBC spooled text output.
CR: Commodore 8-bit machines, Acorn BBC, TRS-80, Apple II family, Mac OS up to version 9 and OS-9
LF: Multics, Unix and Unix-like systems (GNU/Linux, AIX, Xenix, Mac OS X, FreeBSD, etc.), BeOS, Amiga, RISC OS, and others.
RS: QNX pre-POSIX implementation.
但我从未真正注意到在窗户上需要CR，无论如何都要在正确的位置打印。 CR，再次根据维基百科，在类型编写者的时候用于将写头返回到行的开头，然后用于滚动一行的LF。
我的问题是这些天是否真的有必要使用CR以及为什么。如果仅使用LF，哪些系统可能无法正确输出文本？打印机是否仍然需要CR，如果是这样，操作系统是否自动将LF解释为新行并返回行首或CR仍必须在我发送的数据中进行硬编码？
答案 0 :(得分：12)
在C和C ++程序中，您所需要的只是（至少在处理标准库时）\n，当发送到以文本模式打开的任何C / C ++流时（即，当您未在b和fopen中为C ++流指定ios::bin时，会自动转换为当前平台的行终止符。这就是为什么在Windows上你只需要将\n写入任何流，它就会“神奇地”CRLF进入文件/控制台。
为此目的存在整个二进制/文本模式：当你编写文本文件时，进行这种翻译很有用（这种方式在你的字符串中你可以只有\n作为行终止符而不用担心特定平台线路终结器），但是当你编写二进制文件时\n只是一个像其他文件一样的字节，不应该被翻译，否则你会得到损坏的数据。
*仅使用LF（即\n）的NIX系统实际上不进行任何转换，但为了便携性/清晰度目的，正确指定二进制/文本模式仍然是好的。
在C ++中始终使用endl是一个常见错误，\n足以将转换到特定于平台的行终止符。
endl比\n更多的是刷新流缓冲区，这在某些有限的情况下很有用（例如在长时间操作之前在控制台上输出内容），但通常只会慢一些IO（在控制台上它通常不会引人注意，但在文件上）。我通常只使用\n并在实际需要刷新时添加std::flush。
这与标准库有什么关系;在处理其他库YMMV时，您应检查其文档以查看它们是否遵循标准C约定，或者它们是否需要字符串来包含特定于平台的行终止符。