C有__STDC__
,但似乎没有标准的方法来识别一些扩展的C++方言。因此,为了编写可移植的代码,我使用
#define __is_extended \
((__GNUG__ &&!__STRICT_ANSI__) || \
(_MSC_VER && _MSC_EXTENSIONS && __cplusplus) || \
(__IBMCPP__ && __EXTENDED__))
这适用于目前的gcc、XLC和Visual C++。
我们必须按照编译器进行ISO/ANSI测试,对吧?如果是这样,请问您能否提供其他已经被证明可行的编译器建议?
编辑:由于关于这些测试的赞成和反对有很多讨论,这里有一个现实世界的例子。假设有一些头文件stuff.h在多个编译器和多个项目中广泛使用。stuff.h使用了一些特定于编译器的vsnprintf
(在C++11之前未标准化),一些copy_if<>
(在C++98中他们不知道),自己的互斥保护等等。当实现一个干净的C++11变体时,将旧(但值得信赖)实现包装在一些#if __is_extended
(最好:__is_idosyncratic
或!__is_ANSI_C11
)。新的C++11在#else
后面。当仍然编译为C++0x或C++98的翻译单元包括stuff.h时,什么都没有改变。没有编译错误,运行时没有不同的行为。 C++11仍然是实验性的。该代码可以安全地提交到主分支,同事可以研究它,从中学习并应用其组件技术。
__is_extended
的 result 吗? - Christian Hackl/Ze
标志,则会定义_MSC_EXTENSIONS
。解决此问题的方法不是使用/Ze
而是使用/Za
。为什么您要先启用编译器中的扩展,然后将自己的编译器配置视为错误呢? - Christian Hackl/Za
参数,并通过生成的错误消息精确指向代码中的非标准部分,为何不能更优雅地解决它。 - Christian Hackl