最近我正在使用一些字符串,文本输入,类似的东西,我意识到我对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必须仍然在我发送打印的数据中进行硬编码？
Mat*_*lia 12
在你的C和C++程序中你所需要的(至少在处理标准库时)\n,当发送到以文本模式打开的任何C/C++流时(即当你没有指定b为fopen和ios::binC++时) streams),自动转换为当前平台的行终止符.这就是为什么在Windows上你只需要写入\n任何流,它就会变成文件/控制台上的"神奇"CRLF.
整个二进制/文本模式的东西就是为了这个目的而存在的:当你编写一个文本文件时,这个翻译很有用(这种方式在你的字符串中你可以只\n用作行终止符而不用担心特定的平台行终止符),但是当你写的二进制文件\n只是一个像其他文件一样的字节,不应该被翻译,否则你会得到损坏的数据.
*仅使用LF(即\n)的NIX系统实际上不进行任何转换,但为了便携性/清晰度目的,指定正确的二进制/文本模式仍然是好的.
endl在C++中使用always 是一个常见错误,\n足以将转换到特定于平台的行终止符.
什么endl不仅仅是\n刷新流缓冲区,这在某些有限的情况下很有用(例如在长时间操作之前在控制台上输出内容),但通常只会减慢IO(在控制台上它通常不会引起注意,但是在它是文件).我通常只需使用\n并添加一个std::flush实际需要刷新的时候.
这与标准库有关; 在处理其他库YMMV时,您应检查其文档以查看它们是否遵循标准C约定,或者它们是否需要字符串来包含特定于平台的行终止符.