c++ - 零运行时成本功能标志

Question

我们的目标是拥有一个 Feature flag system没有运行时成本。一个简单的 C99 解决方案是:

C99:

#include <stdio.h>

#define flag_1 1

int main()
{
#if flag_1
    printf("Active\n");
#else
    printf("InActive\n");
#endif

    return 0;
}

并不是说这里的 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
    {

    };
}

虽然这个是:

#if tag_flag_1
    class foo
    {

    };
#endif

C99 解决方案的问题:

打字:

if constexpr(flag_not_exists)

会导致编译错误，而:

#if flag_not_exists

不会。

当然，人们总是可以在 C99 中编写这种替代的繁琐解决方案:

#include "stdio.h"

#define flag_1 0

int main()
{
#if flag_1
    printf("Active\n");
#elif defined(flag_1)
    printf("InActive\n");
#else
#error undefined_flag
#endif

    return 0;
}

---

问题:

是否有一种优雅的方法来确保使用不存在(例如拼写错误)的功能标志会导致编译错误？

解决方案很重要:

• 不要求开发人员额外“else #error”的永久纪律。我们都很懒惰……
• 运行时成本为 0
• 支持 bool 运算“#if (feature_1 || feature_2) && !feature_3”
• “特征标志系统”的精确度:当你开发一个新的特征时，你可以修改函数签名，给一个类增加一个成员，改变一个变量的类型，增加一个新的类。 ..它实际上相当于在同一个文件中拥有两个分支(主要和功能)。通过打开和关闭标志从一个切换到另一个。任何代码修改都可以进行功能标记!

我对可能的模板和/或面向宏的解决方案非常好奇。

从评论问题编辑:

使用 C99 的简单解决方案会很好。目前我们的软件使用 Cpp11 编译器进行编译。但即使是 Cpp17 解决方案也适合以后使用……任何解决方案都很好，向后兼容越多越好(因为更多人可以使用它!)。

Answer 1

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

下面的代码 (C++11) 符合以下要求:

• “不需要开发人员额外的“else #error”的永久纪律。我们都是懒惰的......”:实际上只需要一次(static_assert()s定义允许的功能组合)。
• “运行时成本为 0”:是的，这要归功于编译器的优化器(如果已打开)。
• “支持 bool 运算“#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...
    }
}