定义支持/不支持某个功能的HAS_XXX / NO_XXX

Question

为什么Boost C++11开发人员更喜欢NO_XXX而不是HAS_XXX？如您所见，\boost\core\noncopyable.hpp中使用了BOOST_NO_CXX11_DELETED_FUNCTIONS，

#if !defined(BOOST_NO_CXX11_DELETED_FUNCTIONS)
      noncopyable( const noncopyable& ) = delete;
      noncopyable& operator=( const noncopyable& ) = delete;
#else
  private:  // emphasize the following members are private
      noncopyable( const noncopyable& );
      noncopyable& operator=( const noncopyable& );
#endif

如果他们选择了BOOST_HAS_CXX11_DELETED_FUNCTIONS，情况就不会改变。

#if defined(BOOST_HAS_CXX11_DELETED_FUNCTIONS)
      noncopyable( const noncopyable& ) = delete;
      noncopyable& operator=( const noncopyable& ) = delete;
#else
  private:  // emphasize the following members are private
      noncopyable( const noncopyable& );
      noncopyable& operator=( const noncopyable& );
#endif

与使用HAS_XXX相比，使用NO_XXX是否具有优势？

Answer 1

未定义的"has“意味着(a)您检测到该功能缺失，或(b)您忘记运行检测该功能是否缺失的代码。

然后编写依赖于/不依赖于特性的代码；构建在所有4种情况下都成功(特性存在/不存在，检测代码运行/不存在)。但在4种情况中的1种(功能存在，检测代码被跳过)编译了错误的代码。

未定义的"no“表示(a)您检测到该功能存在，或(b)您忘记运行检测该功能是否缺失的代码。

然后，您可以编写依赖于/不依赖于特性的代码。当您忘记运行功能检测代码，并且功能不存在时，构建将失败。

因此，NO减少了1个静默错误案例，并且静态检测程序逻辑错误的硬错误增加了1个。

看起来是个不错的计划。

Answer 2

实际上有一些不同-不是在最终输出上，而是在默认设置上：

• With HAS_XXX semantics，如果您想要某个功能，则需要显式启用该功能，默认值为已关闭的功能。
• with NO_XXX semantics完全相反，默认值为on，但您可以显式禁用它(例如，因为您的编译器不支持它)