Ответ 1
Надеюсь, я полностью понял требования. Если нет, сообщите мне, и я отредактирую или отозму этот ответ.
Код belows (С++ 11) соответствует следующим требованиям:
- "Не требовать постоянной разработки дополнительного" else #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 one version of it just for FeatureFlags::feature_1
// - There another for FeatureFlags::feature_3 provided FeatureFlags::feature_1 is not defined
// - And there 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 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 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 conditionnaly 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 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...
}
}