如何检查#pragma STDC 的状态?
How to check the state of #pragma STDC?
考虑这段代码:
/* t0.c */
#pragma STDC FENV_ACCESS ON
#include "t0.h"
那么在t0.h
中如何查看STDC FENV_ACCESS
的状态呢?
/* t0.h */
/* how to check the state of STDC FENV_ACCESS? */
/* something like: #if STDC FENV_ACCESS == ON */
如果不可能,则:
- 为什么不可能?
- 将此功能添加到 C 标准中是否有用?
(1) Why not possible?
可能 自定义 cpp
正如 rryker 的回答提到的。否则,我会说“不”,因为编译器使用了 pragma,并且 在 之后 cpp
pass/stage.
(2) Will it be useful to add this feature to the C standard?
不,可能不是。由于上述原因。
而且,因为从已经很常见的东西(例如 autoconf
)中吸取教训,我们可以在不更改现有编译器的情况下扭转问题以获得所需的结果。
定义(例如)一个 features.h
:
#ifdef STDC_FENV_ACCESS_ON
#if STDC_FENV_ACCESS_ON
#pragma STDC FENV_ACCESS ON
#else
#pragma STDC FENV_ACCESS OFF
#endif
#endif
更新:
Re: "custom cpp as rryker's answer mentioned": hm, where is the rryker's answer? I don't see it. –
pmor
我写道 before rryker [部分] 删除了他的回答,因为无法立即解决来自 HolyBlackCat 的 critique/comments。 我的推断是 rryker 可以改进他的答案并取消删除它,所以我留下了参考。
link rryker 的回答基于 clang
提供的特定扩展:https://clang.llvm.org/docs/LanguageExtensions.html rryker 的回答提到的功能是:__has_feature
和 __has_extension
宏 [从版本 10 开始].
这是参考。不过,结合我的一些推测,我会尝试总结一下。
IIRC,clang 的 cpp
是 而不是 一个单独的程序,它只是松散地连接到编译器 [例如就像 gcc
].
对于 clang
,预处理器是编译器本身 [更多] 紧密集成的阶段。我的假设是[最初]这样做是为了速度和代码重用。
但是,作为其“副作用”:
clang 的 cpp
可以更深入地了解编译器的内部工作原理。
而且,如果它更多 efficient/desirable,clang 的 cpp
阶段也可以做更多的早期(例如)pragma
处理。
而且,cpp 可以访问(例如)编译器看到的所有 -f*
arguments/options。
因此,它具有使上述 __has_*
宏上的 #if/#ifdef
可行的所有工具。
除了其他答案之外,如果 t0.c
实际上在您的控制之下,您可以在使用 #pragma 时定义适当的宏。
/* t0.c */
#pragma STDC FENV_ACCESS ON
#define PRAG_FENV_ACCESS_ON
#include "t0.h"
这独立于工具链供应商。它是用于检查预处理器中是否存在 typedef
的同一主题的变体。
考虑这段代码:
/* t0.c */
#pragma STDC FENV_ACCESS ON
#include "t0.h"
那么在t0.h
中如何查看STDC FENV_ACCESS
的状态呢?
/* t0.h */
/* how to check the state of STDC FENV_ACCESS? */
/* something like: #if STDC FENV_ACCESS == ON */
如果不可能,则:
- 为什么不可能?
- 将此功能添加到 C 标准中是否有用?
(1) Why not possible?
可能 自定义 cpp
正如 rryker 的回答提到的。否则,我会说“不”,因为编译器使用了 pragma,并且 在 之后 cpp
pass/stage.
(2) Will it be useful to add this feature to the C standard?
不,可能不是。由于上述原因。
而且,因为从已经很常见的东西(例如 autoconf
)中吸取教训,我们可以在不更改现有编译器的情况下扭转问题以获得所需的结果。
定义(例如)一个 features.h
:
#ifdef STDC_FENV_ACCESS_ON
#if STDC_FENV_ACCESS_ON
#pragma STDC FENV_ACCESS ON
#else
#pragma STDC FENV_ACCESS OFF
#endif
#endif
更新:
Re: "custom cpp as rryker's answer mentioned": hm, where is the rryker's answer? I don't see it. – pmor
我写道 before rryker [部分] 删除了他的回答,因为无法立即解决来自 HolyBlackCat 的 critique/comments。 我的推断是 rryker 可以改进他的答案并取消删除它,所以我留下了参考。
link rryker 的回答基于 clang
提供的特定扩展:https://clang.llvm.org/docs/LanguageExtensions.html rryker 的回答提到的功能是:__has_feature
和 __has_extension
宏 [从版本 10 开始].
这是参考。不过,结合我的一些推测,我会尝试总结一下。
IIRC,clang 的 cpp
是 而不是 一个单独的程序,它只是松散地连接到编译器 [例如就像 gcc
].
对于 clang
,预处理器是编译器本身 [更多] 紧密集成的阶段。我的假设是[最初]这样做是为了速度和代码重用。
但是,作为其“副作用”:
clang 的
cpp
可以更深入地了解编译器的内部工作原理。而且,如果它更多 efficient/desirable,clang 的
cpp
阶段也可以做更多的早期(例如)pragma
处理。而且,cpp 可以访问(例如)编译器看到的所有
-f*
arguments/options。因此,它具有使上述
__has_*
宏上的#if/#ifdef
可行的所有工具。
除了其他答案之外,如果 t0.c
实际上在您的控制之下,您可以在使用 #pragma 时定义适当的宏。
/* t0.c */
#pragma STDC FENV_ACCESS ON
#define PRAG_FENV_ACCESS_ON
#include "t0.h"
这独立于工具链供应商。它是用于检查预处理器中是否存在 typedef
的同一主题的变体。