利用C++继承能否实现强类型定义并保证执行效率？

我有一个用于描述GPU内存分配的类型RenderName，若将描述“shader”的实例传入期望“texture”的函数会引发严重问题。因此我希望借助C++类型系统避免此类错误，同时在需要时仍能将所有RenderName视为同一类型处理。

请问像我这样通过继承实现TextureName等派生类，能否达成上述行为且不会导致编译器生成低效代码？

相关代码 #

class RenderName {
public:
    // 构造、析构函数执行大量复杂操作，类似智能指针
    RenderName();
    RenderName(RenderName && other);
    RenderName(const RenderName & other);
    RenderName & operator=(RenderName && other);
    RenderName & operator=(const RenderName & other);
    ~RenderName();

    uint32 name() const;
    
protected:
    RenderName(uint32 engine, uint32 type); 

    uint32 m_guts;
};


// 强类型"别名"
class TextureName : public RenderName {};
class BufferName : public RenderName {};
class ShaderName : public RenderName {};

static_assert(sizeof(TextureName) == sizeof(RenderName), "这些子类型应保持相同大小");

期望行为示例 #

BufferName allocateBuffer() { ... }
void bindShader(ShaderName name) { ... }
void debugName(RenderName name) { ... }

int main() {
    std::vector<RenderName> array;
    TextureName name;
    RenderName base;

    // 希望这些操作编译失败
    name = base;
    name = allocateBuffer(); 
    bindShader(name); 

    // 但以下操作应能正常执行
    base = name;
    debugName(name);
    array.push_back(name);  
}

这种继承方案完全可以实现你想要的类型安全目标，且不会产生任何性能损耗，具体分析如下：

1. 类型安全需求的满足

   • 你定义的TextureName等派生类都是空类，没有新增任何成员或函数，编译器会将它们视为RenderName的强类型别名。
   • 由于派生类默认的赋值运算符、构造函数只接受同类型对象，你期望编译失败的操作（比如用RenderName给TextureName赋值、把TextureName传给bindShader）都会被编译器直接拦截，完美实现了不同资源类型的隔离。
   • 而派生类到基类的隐式转换是C++继承的默认行为，所以base = name、debugName(name)这类统一处理基类的操作可以正常编译，满足你对统一处理的需求。

2. 性能层面的保证

   • 你的static_assert已经确保派生类与基类大小一致，而C++的**空基类优化（EBO）**会让编译器彻底消除派生类的额外开销——派生类的内存布局和基类完全相同，没有虚表、额外成员等冗余数据。
   • 所有针对派生类的操作，编译器都会直接优化为基类的操作，不会产生任何额外的函数调用或内存操作，性能和直接使用RenderName完全一致。
   • 由于没有定义虚函数，不存在虚表查找的开销，所有函数调用都是静态绑定，效率拉满。

3. 额外优化建议

   • 可以给每个派生类添加专属的构造函数，避免通过基类的保护构造函数意外创建错误类型的对象，例如：

     class TextureName : public RenderName {
     public:
         TextureName(uint32 engine) : RenderName(engine, TEXTURE_TYPE) {}
     };
     

   • 若需要更严格的类型隔离，可以将基类的默认构造函数设为保护，只允许派生类通过专属构造创建对象，进一步减少误用的可能。

内容的提问来源于stack exchange，提问作者Anne Quinn