由于预期会被更有经验和受过教育的人割裂,我只想为我下面的问题被任何“手波式”或不准确的措辞所困扰而道歉。
我对文本文件、扫描器、解析器(以及总体上的编译器)和C语言有一点了解,所以希望这足以让我的查询内容得到理解。
当我在我的Windows 10计算机上使用gcc
编译用C编写的文本文件时,编译器最初在其早期阶段看到了什么?
例如,假设我有一个只包含C语言关键字for
的文本文件。这个文件里没有别的东西了。当我提示gcc
对该文件执行操作时,编译器是否只看到f
(01100110作为其8位表示形式)、o
(01101111)和r
(01110010)的二进制代码表示?我猜想可能还有其他二进制代码告诉编译器“这是一个文本文件”。
那么编译器所执行的机器级代码是否类似于这样呢?
{二进制代码在文件开头告诉编译器这是文本}_01100110_01101111_01110010_{文件末尾的二进制代码告诉编译器这是文件的结尾}
其中01100110_01101111_01110010是for
的机器级表示。
谢谢!
发布于 2020-06-19 21:58:39
用输入
用于的
在文本文件中,
编译器将首先看到您调用它来处理该文件的事实。
由此推断它必须是一个带有c代码的文本文件。否则你为什么要让它处理那个文件。因此,在文件内容中没有“{二进制代码在文件开头告诉编译器这是文本}”。
是的,它是f
,o
,r
。
它使用操作系统的服务/函数(在某些时候还提供了最后一个字符/字节已被读取的信息)这样做。但是,该信息并不包含在文件内容本身中。所述信息最终来自文件系统(通过操作系统访问)在文件上的元数据,例如其长度(与其他数据一起,例如媒体上的确切位置)。
因此,文件内容中没有“文件末尾的{二进制代码”来告诉编译器这是文件}的结尾。
唯一接近“{二进制}”信息的是换行符\n
或对返回和换行符\r\n
,这取决于环境。它们表示两行之间的边框(可视为换行符的开始或前一行的结尾)。
为了关注你的问题,我跳过了一些细节,比如前处理器的参与。
严格地说,当编译器(或程序中执行编译工作的部分)工作时,预处理程序(或程序中完成预处理工作的部分)已经完成。
https://stackoverflow.com/questions/62482052
复制相似问题