预处理器输出文件是有效的C/C++文件吗？

Question

我有两个文件作为qwe.h

#ifndef QWE_H
#define QWE_H
//#include <iostream>
int asd();
#endif

qwe.cc

#include "qwe.h"
int asd()
{
std::cout<<"asdasd";
}

只在g++ -E qwe.cpp > op4给出以下输出时运行预处理器

# 1 "qwe.cpp"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "qwe.cpp"
# 1 "qwe.h" 1




int asd();
# 2 "qwe.cpp" 2
int asd()
{
 std::cout<<"asdasd";
}

预处理程序的输出不应该是一个有效的C/C++文件吗？语句"# int string int“的含义是什么？

Answer 1

GCC做出了合理的努力，使预处理器输出转储仍然是有效的源代码。但一般的答案是否定的，这并不是为了这个目的。

您还可以将-P选项与-E一起传递，以使其更具机器可读性，降低人的可读性。更多的空白将被删除，# 234 "blah.h"标记将不会出现。

预处理器的输出不应该是一个有效的c/c++文件吗？

预处理程序所做工作的很大一部分是对源进行词法，或者将源划分为令牌。然后扩展宏，根据一定的规则生成令牌和空格。宏可以生成没有空格分隔的标记。根据标准，直接呈现为文本的预处理输出通常不可能再划分回正确的标记。

GCC为了满足人们的期望，通过引入更多的空格来满足预处理器输出可以表示为文本的期望，但这并不是一件值得信赖的事情，当然也不适合其他编译器。

Answer 2

它们是用于跟踪其他文件中包含的文件的位置的行号，这在生成编译器警告和错误时非常有用。

参见维基百科上的这篇文章。

Answer 3

没有语言要求预处理输出必须是有效的C++ --甚至不要求预处理器的输出是可用的。但是g++通常使用的预处理程序(也许总是这样？)生成本身可以编译为C++的输出。

# int string int语句的含义是什么？

任何以#开头的行都是预处理指令。如果在其他情况下无法识别#后面的令牌，则#后面的行部分为非指令。(不管名称如何，非指令都是预处理指令。)非指令通常被忽略。

通常是预处理程序处理所有预处理指令，包括非指令，但在本例中，以#开头的一些行传递给编译器本身，编译器知道如何忽略它们。

您可以通过将预处理器输出提供给编译器来演示这一点：

g++ -E foo.cpp > foo_preprocessed.cpp
g++ -c foo_preprocessed.cpp

如果foo.cpp有预处理指令，特别是#include指令，foo-preprocessed.cpp可能会大得多--但是编译器仍然能够处理它。

语言标准以令牌而不是tex定义预处理器输出，但它允许足够的灵活性，因此文本是表示所需令牌序列的有效方法。

(所有这些都适用于C和C++。)