如何区分预处理器指令和编译器指令
How to distinguish preprocessor and compiler directives?
我被告知GCC中的#pragma omp
指令是编译器的指令,而不是预处理器的指令。
正确吗?
如何区分预处理器和编译器的指令?
gcc -E
只运行预处理器。所以检查它的输出:任何剩下的东西都是编译器应该注意的。
#pragma
控制的事情无法想象地由预处理器完成,因此,在这些情况下,它必须是一个编译器指令(或者在理论上,它可以被预处理器替换为一个等效的编译器指令——如果你关心差异,那么再次,gcc -E
将显示发生了什么)。然而,#pragma
所做的一些事情与预处理(#pragma once
)有关,因此在这些情况下,它必须是一个预处理器指令。
你的例子#pragma omp
是一个编译器指令的两个测试。一般来说,预处理器还没有聪明到可以并行化代码。它甚至不理解它看到的大部分c++代码,基本上它所能做的就是用常量进行整数运算、宏替换和清除文本。要使用gcc -E
进行直接测试,请尝试以下文件:
#if 1
#pragma omp
#endif
输出是一些文件名/行号注释加上:
#pragma omp
所以我们观察到#if
和#endif
已经被预处理器处理了,而#pragma omp
没有。
这是来自gcc文档的引用
本手册记录了对预处理器本身有意义的pragmas。其他的程序对C或c++编译器是有意义的。它们在GCC手册中有文档。
按此分为预处理器pragmas和非预处理器pragmas。
如何区分预处理器和编译器的指令?
预处理器指令在C标准中指定,编译器指令在编译器手册中描述。
关于你的编辑,链接的页面没有提到#pragma omp
,如果你把它和上面的引用结合起来,我认为这个pragma不是针对预处理器的。
相关文章:
- 保证编译器指令在C++中重新排序
- 防止编译器分离函数的指令
- x86 - 为什么编译器在下一条指令中插入看似毫无意义的JMP?
- 是跨平台和跨编译器 #error 指令
- 为什么延迟指令导致编译器错误
- 为什么使用某些编译器上的指令与私人的超载冲突
- 编译器生成昂贵的MOVZX指令
- 使库函数模板化以避免编译器指令是否有益?
- 使用Microsoft编译器生成 CMOV 指令
- 如何指定Xcode链接器的库和Xcode编译器的预处理器指令
- 如何在各种编译器中定义 __cplusplus 指令
- __cplusplus已定义和未定义的编译器指令
- 编译器指令在C++中的工作
- 是否可以(如何)在 c/c++ 代码中给出编译器指令
- 编译器是如何知道我的CPU的指令集的
- visual编译器指令在C++中重新排序优化(以及禁止它们的原因)
- 由于库与EXE项目中的编译器指令不匹配,内存损坏
- 在这种情况下,编译器可以根据自己的意愿对指令进行重新排序
- 让编译器生成adc指令
- 为什么Intel编译器忽略了Intel MIC的非时序预取指令