零运行时成本功能标志

我希望我完全理解要求。如果没有，请告诉我，我会编辑或撤回这个答案。

下面的代码 (C++11( 通过以下方式符合要求：

• "不需要开发商对额外的"其他 #error"进行永久纪律处分。我们都很懒..."：实际上只需要一次(定义允许的特征组合的static_assert()(。
• "运行时成本为 0"：是的，感谢编译器的优化器(如果打开(。
• "支持布尔运算"#if (feature_1 || feature_2( && ！feature_3"：是的，当然，但不使用预处理指令
• ">特征标志系统"的精度[...见OP的问题和评论]"：不完全。这里没有条件编译，因此始终编译整个代码，并且无论功能组合如何，都必须定义运行时代码中使用的所有类型(即使它们是不同的方式(。但是，未使用的代码会被编译器的优化器(如果打开(剥离。

话虽如此，这种解决方案使代码复杂化。下面的内容在软件的某些精确部分很有用，但我不会使用它来处理代码的整个条件激活。我通常将这些东西与普通分支和预处理器指令结合使用。因此，请将下面的代码作为"极端的小例子"。

#include <iostream>
// Having all your flags encapsulated in a namespace or in a class allows you to avoid errors tied to typos:
// - "#if feaature_1" (notice the typo in 'feaature') would just exclude some code silentely
// - but "if (FeatureFlags::feaature_1)" (same typo) produces a compile error, which is better
class FeatureFlags
{
public:
static constexpr bool feature_1 = false; // This would also work with 'const' instead of 'constexpr' actually.
static constexpr bool feature_2 = true;
static constexpr bool feature_3 = true;
};

// We want to define a conditional class Foo. But we can't just use FeatureFlags to do conditional compile, and 
// we can't test FeatureFlags with preprocessor #directives either. So we split it as follow:
// - There's one version of it just for FeatureFlags::feature_1
// - There's another for FeatureFlags::feature_3 provided FeatureFlags::feature_1 is not defined
// - And there's a default one that deliberately cause a compile time error as we want
//   either FeatureFlags::feature_1 or FeatureFlags::feature_3 to be activated, in this example.
// This pure virtual class is just there to cause compile-time errors should we forget to
// implement a part of the class's behaviour in our Foo variants. 
// This is not mandatory: if we don't use such an interface we'll just have compile-time errors later 
// in the run-time code instead of having them at class definition level.
// This doesn't cause performances issues as the compiler's optimizer will handle that for us, we'll see later.
class Foo_Interface
{
public:
virtual ~Foo_Interface() 
{}
virtual void doSomething() = 0;
};

// Will be stripped out by modern compilers' optimizers if FeatureFlags::feature_1 is false
// Side note: Methods are implemented inline just to have a compact example to copy/paste. 
// It would be best to have them in a separate .cpp file of course, as we usually do.
class Foo_Feature1 : public Foo_Interface
{
public:
Foo_Feature1()
: i(5)
{}
virtual ~Foo_Feature1() 
{}
virtual void doSomething()
{
std::cout << "Foo_Feature1::doSomething() with " << i << std::endl;
}
private:
int i;
};

// Will be stripped out by modern compilers' optimizers if FeatureFlags::feature_1 is true or FeatureFlags::feature_3 is false
class Foo_NotFeature1But3 : public Foo_Interface
{
public:
Foo_NotFeature1But3()
: d(1e-5)
{}
virtual ~Foo_NotFeature1But3() 
{}
virtual void doSomething()
{
std::cout << "Foo_NotFeature1But3::doSomething() with " << d << std::endl;
}
private:
double d;
};

// Will be stripped out by modern compilers' optimizers if FeatureFlags::feature_1 is true or FeatureFlags::feature_3 is true
class Foo_Default : public Foo_Interface
{
public:
Foo_Default()
{
// This produces an error at compile time should the activated features be unconsistant.
// static_assert(cdt,msg) can be used everywhere, not only in blocks. It could have been right under 
// the definition of FeatureFlags for example. It really depends on where you would like the error to appear.
static_assert(FeatureFlags::feature_1 || FeatureFlags::feature_3, "We shouldn't be using Foo_Default, please enable at least feature 1 or 3");
}
virtual ~Foo_Default()
{}
virtual void doSomething()
{}
};

// Now we can conditionally define Foo:
// - Foo is Foo_Feature1 if FeatureFlags::feature_1 is true. 
// - Otherwise, it is either Foo_NotFeature1But3 or Foo_Default depending on FeatureFlags::feature_3
typedef std::conditional
<
FeatureFlags::feature_1,
Foo_Feature1,
std::conditional<FeatureFlags::feature_3, Foo_NotFeature1But3, Foo_Default>::type
>::type Foo;

void main()
{
// What follows is automatically inlined in release mode, no virtual table. Not even an object.
// If Foo becomes bigger or more complicated, this might change. But in that case this means the
// cost of the vtable becomes neglictible. All of this can perfectly be done with no inheritance at 
// all though (see comments at Foo_Interface's definition)
Foo f;
f.doSomething();

if (FeatureFlags::feature_1)
{
// Do something or not depending on feature_1.
}
if (FeatureFlags::feature_2)
{
// Do something or not depending on feature_2.
}
if ((FeatureFlags::feature_1 || FeatureFlags::feature_2) && !FeatureFlags::feature_3)
{
// Why not, after all, but that sounds odd...
}
}

如果缺少对不存在的标志的诊断是预处理器方法的唯一问题，您也可以改用类似函数的宏：

#define feature_flag() 0
int main()
{
#if feature_flag()
printf("A");
#else
printf("B");
#endif
}

如果该标志不存在，这将触发诊断，但行为类似于普通宏。

并不是说这里的C++ 17解决方案看起来很优雅：

#include <iostream>
constexpr  bool tag_flag_1 = true;
constexpr  bool tag_flag_2 = true;

int main()
{
if constexpr(tag_flag_1)
{
std::cout << "Active" << std::endl;
}
else
{
std::cout << "InActive" << std::endl;
}
return 0;
}

但是不起作用，因为"if constexpr"结构仅在"if"结构>有效。例如，此代码无效：

if constexpr(tag_flag_1)
{
class foo
{
};
}

模板来救援。模板专业化是IMO不错的解决方案：

template<bool selectFeature>
class FooImpl;
template<>
class FooImpl<true>
{
};
using Foo = FooImpl<tag_flag_1>;

或者更好：

template<bool selectFeature = tag_flag_1>
class Foo;
template<>
class Foo<true>
{
};

您可以使用 SFINAE 禁用某些功能(如果功能可用(。

对于复杂的功能标志，这也很好用：

constexpr  bool tag_flag_1 = true;
constexpr  bool tag_flag_2 = true;
constexpr  bool tag_flag_3 = true;
template<bool future_1 = tag_flag_1, bool future_2 = tag_flag_2, bool future_2 = tag_flag_2>
class Foo;
template<>
class Foo<true, true, true>
{
};
// when feature 1 is disabled we do not care 
// about state of feature 2
template<bool anyFeature2>
class Foo<false, anyFeature2, true>
{
};
....
template<>
class Foo<false, false, false>
{
};
....