C++ 换行和回车

最近我在处理一些字符串、文本输入之类的事情，我意识到我对两个字符有点困惑——LF（10）和CR（13）。每次我需要启动新行时，我使用STD::Endl用于C++字符串，\n是C字符串的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.

但我从未真正注意到在windows上需要CR，所有的东西都会在正确的位置打印出来。根据维基百科的说法，在打字机时代，CR被用来将书写头返回到行的开头，然后LF被用来滚动一行

---

我的问题是，现在是否真的有必要使用CR以及为什么。如果仅使用LF，哪些系统可能无法正确输出文本？打印机是否仍然需要CR，如果是这样，OS是否自动解释LF既为新行又返回到开始行还是CR必须仍然硬编码在我发送的数据中？

< P>在您的C和C++程序中，您所需要的（至少，当处理与标准库时）是<代码> \n>代码>，其中，当发送到任何文本模式下的C/C++流（即当您不指定<代码> B<代码> > <代码> fOpen< /COD>和 iO::bin >代码> C++时，将自动转换为当前平台的行终止符。这就是为什么在Windows上，您只需将

\n

写入任何流，它就会“神奇地”变成控制台上的文件/中的CRLF

整个二进制/文本模式就是为了这个目的而存在的：当你写一个文本文件时，有这样的翻译是很有用的（这样在你的字符串中你就可以有

\n

作为行终止符，而不用担心特定的平台行终止符），但是，当您编写二进制文件时，

\n

与其他文件一样，只是一个字节，不应进行翻译，否则会导致数据损坏

*仅使用LF（即

\n

）的NIX系统实际上不会进行任何转换，但为了便于移植/清晰起见，正确指定二进制/文本模式仍然是一个不错的选择

在C++中使用Cyth>代码> EntL\/Cuff>是一个常见错误，>\N/COD>足以将该翻译转换为特定于平台的行终止符。

endl

比

\n

做得更多的是刷新流缓冲区，这在某些有限的情况下可能很有用（例如，在长时间操作之前在控制台上输出一些东西），但通常只是减慢IO（在控制台上通常不明显，但在文件上是）。我通常只使用

\n

并在实际需要刷新时添加

std:：flush

---

---

这与标准库有关；当处理其他的库YMMV时，你应该检查他们的文档，看看它们是否遵循标准的C约定，或者它们需要字符串来包含特定于平台的行终止符。

Windows上的一些程序将只在LF中工作，有些不会。“使用C++中的总是Endl是一个常见的错误”——为什么它是错误的？我只使用它。在我的例子中，输出速度的减慢一直是无关紧要的。@Konrad:因为继续刷新缓冲区是无用的，并且可能会出现性能问题（它部分违背了缓冲区的用途）。在我看来，它可以在控制台上正常运行（在控制台上，你没有写很多文本，而且显示速度也慢了），在文件上不正常，如果你在短行中写很多数据，它可能会影响性能。@KonradRudolph减速可能与你“无关”，但这并不意味着它通常与你无关。如果你在做繁重的控制台I/O，那么它肯定不再无关紧要了。@MahmoudAl Qudsi如果你在做控制台I/O，那么这可能是你最不担心的。如果您直接或通过管道写入文件，那么这就变得相关了。控制台上的输出无论如何都很慢。啊，是的，对不起。我一次评论了几个问题。