在编译时有效配置类层次结构

我知道您有两个重要的要求：

1. 数据类型在编译时是已知的
2. 程序流在编译时已知

CRTP不会真正解决您试图解决的问题，因为它会允许HardwareLayer调用Sub_generic、Middle_generic或TopLevel上的方法，我认为这不是您想要的。

使用Trait模式（另一个参考）可以满足您的两个要求。下面是一个例子，证明这两个要求都得到了满足。首先，我们定义了表示您可能想要支持的两个Hardwares的空壳。

class Hardware_A {};
class Hardware_B {};

然后让我们考虑一个类，它描述了一个对应于Hardware_A的一般情况。

template <typename Hardware>
class HardwareLayer
{
public:
    typedef long int64_t;
    static int64_t getCPUSerialNumber() {return 0;}
};

现在让我们来看看Hardware_B:的专业化

template <>
class HardwareLayer<Hardware_B>
{
public:
    typedef int int64_t;
    static int64_t getCPUSerialNumber() {return 1;}
};

现在，下面是Sub_generic层中的一个用法示例：

template <typename Hardware>
class Sub_generic
{
public:
    typedef HardwareLayer<Hardware> HwLayer;
    typedef typename HwLayer::int64_t int64_t;
    int64_t doSomething() {return HwLayer::getCPUSerialNumber();}
};

最后，一个执行两种代码路径并使用两种数据类型的简短main：

int main(int argc, const char * argv[]) {
    std::cout << "Hardware_A : " << Sub_generic<Hardware_A>().doSomething() << std::endl;
    std::cout << "Hardware_B : " << Sub_generic<Hardware_B>().doSomething() << std::endl;
}

现在，如果您的HardwareLayer需要维护状态，这里有另一种实现HardLayer和Sub_generic层类的方法。

template <typename Hardware>
class HardwareLayer
{
public:
    typedef long hwint64_t;
    hwint64_t getCPUSerialNumber() {return mySerial;}
private:
    hwint64_t mySerial = 0;
};
template <>
class HardwareLayer<Hardware_B>
{
public:
    typedef int hwint64_t;
    hwint64_t getCPUSerialNumber() {return mySerial;}
private:
    hwint64_t mySerial = 1;
};
template <typename Hardware>
class Sub_generic : public HardwareLayer<Hardware>
{
public:
    typedef HardwareLayer<Hardware> HwLayer;
    typedef typename HwLayer::hwint64_t hwint64_t;
    hwint64_t doSomething() {return HwLayer::getCPUSerialNumber();}
};

这里是最后一个变体，其中只有Sub_generic实现发生了变化：

template <typename Hardware>
class Sub_generic
{
public:
    typedef HardwareLayer<Hardware> HwLayer;
    typedef typename HwLayer::hwint64_t hwint64_t;
    hwint64_t doSomething() {return hw.getCPUSerialNumber();}
private:
    HwLayer hw;
};

按照与F类似的思路，您可以有这样的目录布局：

Hardware/
  common/inc/hardware.h
  hardware1/src/hardware.cpp
  hardware2/src/hardware.cpp

简化接口，只假设存在一个硬件：

// sub_generic.h
class Sub_generic {
        Hardware _hardware;
};

然后只编译包含该平台硬件的.cpp文件的文件夹。

这种方法的好处是：

• 了解正在发生的事情并添加硬件很简单3
• 硬件.h仍然充当您的API
• 它去掉了编译器的抽象（出于速度考虑）
• 编译器1不需要编译hardware2.cpp或hardware3.cpp，它们可能包含编译器1不能做的事情（如内联程序集或其他编译器2特定的事情）
• hardware3可能会因为一些你还没有考虑过的原因而变得复杂得多。。所以给它一个完整的目录结构可以封装它

由于这是针对硬实时嵌入式系统的，通常您会选择C类型的解决方案，而不是C++。

对于现代编译器，我想说c++的开销并没有那么大，所以这并不完全是性能问题，但嵌入式系统倾向于使用c而不是c++。你试图构建的将类似于一个经典的设备驱动程序库（比如ftdi芯片库）。

那里的方法（因为它是用C写的）类似于你的F，但没有编译时选项-你会在运行时根据PID、VID、SN等来专门化代码

现在，如果您要使用c++来实现这一点，那么模板可能是您的最后一个选择（代码可读性通常比模板带来的任何优势都要高）。所以你可能会选择类似于A的东西：一个基本的类继承方案，但不需要特别花哨的设计模式。

希望这能帮助。。。

我假设这些类只需要创建一次，并且它们的实例在整个程序运行时都会持续存在。

在这种情况下，我建议使用对象工厂模式，因为工厂只会运行一次来创建类。从那时起，专门的类都是已知的类型。