对于旧Mac OS,C编译器下'\n'的值是多少？
Kei*_*son 46 c c++ mac-classic
背景:
在最高版本为9的Mac OS版本中,文本文件的标准表示使用ASCII CR(回车)字符,值十进制13,以标记行的结尾.
与早期版本不同,Mac OS 10与UNIX类似,并使用ASCII LF(换行符)值十进制值10来标记一行的结尾.
问题是,什么是字符常量的值'\n',并'\r'在C和C++编译器Mac OS发布OS X之前？
可以采用(至少)两种可能的方法:
- 治疗
'\n'作为ASCII字符LF,并将其转换为与从CR上输出,并从文本流输入(类似于LF和CR-LF在Windows系统之间的转换); 要么 - 治疗
'\n'作为ASCII CR字符,这需要对输入或输出的任何转换.
第二种方法会有一些潜在的问题.一个是假设'\n'LF的代码可能会失败.(无论如何,这样的代码本质上是不可移植的.)另一个是仍然需要一个不同的值'\r',并且在基于ASCII的系统上,CR是唯一合理的值.并且C标准不允许'\n' == '\r'(感谢mafso找到引文,5.2.2第3段),因此必须使用其他一些值'\r'.
在Mac OS N下编译和执行时,此C程序的输出是多少,N小于10？
#include <stdio.h>
int main(void) {
printf("'\\n' = %d\n", '\n');
printf("'\\r' = %d\n", '\r');
if ('\n' == '\r') {
printf("Hmm, this could be a problem\n");
}
}
这个问题适用于C和C++.我认为两者的答案都是一样的.
答案也可能因C编译器而异 - 但我希望编译器实现者能够保持彼此的一致性.
为了清楚起见,我不是要问Mac OS的旧版本用于表示文本文件中的行尾.我的问题只是关于常量的值'\n'和'\r'C或C++源代码.我知道打印'\n'(无论它的值是什么)到文本流会导致它被转换为系统的行尾表示(在这种情况下,ASCII CR); C标准要求该行为.
dus*_*uff 45
字符常量的值\r,并\n在经典Mac OS环境完全一样的,因为它是在其他地方:\r是CR是ASCII 13(0x0d); \nLF是ASCII 10(0x0a).Classic Mac OS上唯一不同的\r是用作文本编辑器中的"标准"行,就像\n在UNIX系统上或\r\nDOS和Windows系统上使用的那样.
以下是在Mac OS 9上运行Metrowerks CodeWarrior的简单测试程序的屏幕截图,例如:
请记住,Classic Mac OS系统没有系统范围的标准C库!类似的函数printf()仅作为编译器特定库的一部分出现,如SIOUX for CodeWarrior,它通过将输出写入带有文本字段的窗口来实现C标准I/O. 因此,标准文件I/O的某些实现可能已经在\r和之间执行了一些自动转换\n,这可能是您正在考虑的内容.(例如,\r\n如果你没有将"b"标志传递给许多Windows系统做类似的事情fopen().)然而,在Mac OS工具箱中肯定没有类似的东西.
- 这个答案是对的.但是,还有一个可用的标准库的变体,它解释了以文本模式打开的文件.也就是说,如果文件包含\ r \n(13),则在文本模式下读取时会得到\n(n).在输出时,你会写一个\ r \n(13),它实际上会以\n(10)的形式写入磁盘. (2认同)
- @LưuVĩnhPhúc:那里有Apple的[MPW](http://en.m.wikipedia.org/wiki/Macintosh_Programmer's_Workshop),这对开发人员来说是一个很好的环境 - 你可以像shell(或终端)一样使用它,但是每个"会话"也是一个可编辑的文本文档 - 我想念它. (2认同)
我做了一个搜索,发现这个页面有一个旧的讨论,特别是以下内容:
Metrowerks MacOS实现更进一步,通过颠倒CR和LF在涉及文件的i/o中的'\ r'和'\n'转义的重要性,而不是在任何其他上下文中.这意味着如果你在文本模式下打开一个FILE或fstream,每个'\ r'将作为LF输出,每个'\n'输出为CR,输入也是如此 - 逃逸 - to-ASCII-binary对应关系是相反的.但是它们在内存中并没有被反转,例如sprintf()到缓冲区或std :: stringstream.我发现这令人困惑,如果不是非标准的话,至少比其他实现更糟糕.
事实证明MSL有一个解决方法 - 如果你以二进制模式打开文件,那么'\n'总是== LF和'\ r'总是== CR.这就是我想要的,但是在获取这些信息时,我也从那里的人那里获得了很多理由,这是获得我想要的"标准"方式,当我觉得这更像是他们的错误的解决方法实现.毕竟,CR和LF是7位ASCII值,我希望能够以文本模式打开文件的标准方式使用它们.
(答案清楚地表明这确实不违反标准.)
所以显然至少有一个实现使用\n和\r使用通常的ASCII值,但是将它们转换为(非二进制)文件输出(通过交换它们).