能否通过虚函数实现仅静态多态？——《静态多态：使用final或模板？》的跟进问询

首先直接给你结论：C++标准里目前完全没有你设想的[[abstract]]这类属性——也就是那种允许基类定义纯虚函数接口，但彻底禁止用基类指针/引用指向派生类实例、同时让编译器优化掉虚调用开销的特性。接下来我会拆解背后的原因，以及现有替代方案。

为什么这类特性不存在？ #

要理解这点，得先戳破静态多态和运行时多态的核心差异：

• 运行时多态的本质是动态绑定：基类指针/引用调用虚函数时，实际执行的函数由运行时对象的真实类型决定。这依赖虚函数表（vtable）和虚表指针（vptr），带来了微小但不可避免的运行时开销，换来了“运行时动态切换行为”的灵活性。
• 静态多态的本质是编译期绑定：所有函数调用的目标在编译阶段就完全确定，没有任何运行时开销，但代价是必须在编译时明确所有用到的类型，无法在运行时动态变更。

你设想的[[abstract]]属性，本质是想保留“基类封装主逻辑、派生类实现细节”的代码结构，但抛弃动态绑定的开销，同时禁止基类指针的使用。但这里存在逻辑矛盾：虚函数的唯一设计目的就是支持动态绑定，如果禁止基类指针/引用指向派生类，那虚函数的存在就失去了意义——编译器完全可以把这些虚函数优化成普通非虚函数，但这和直接用CRTP实现静态多态没有本质区别，只是写法不同而已。

另外，C++的设计哲学是不为程序员不需要的特性买单。添加这类特性会增加语言的复杂度，但带来的收益完全可以通过现有特性（比如CRTP）实现，所以标准委员会没有必要专门为它开辟语法。

现有替代方案：实现类似意图的优雅写法 #

虽然没有你想要的语法，但有成熟的方案能实现“基类封装逻辑、派生类实现细节、编译期绑定”的需求：

方案1：CRTP（奇异递归模板模式） #

这是C++实现静态多态的标准方案，完美匹配你的需求：

template<typename Derived>
class Base {
public:
    void bar() {
        // 编译期就确定调用的是Derived::foo，无虚调用开销
        static_cast<Derived*>(this)->foo();
        // 这里可以写所有主逻辑代码
    }
};

class Derived1 : public Base<Derived1> {
private:
    void foo() { /* Derived1的自定义实现 */ }
    // 让基类能访问私有成员foo
    friend class Base<Derived1>;
};

class Derived2 : public Base<Derived2> {
private:
    void foo() { /* Derived2带数据的自定义实现 */ }
    int data;
    friend class Base<Derived2>;
};

这个方案的优势是纯编译期处理，没有任何虚函数开销，代码结构也和你设想的高度一致——基类负责主逻辑，派生类只需要实现细节函数。唯一的区别是基类是模板类，需要把派生类作为模板参数传递。

方案2：非虚函数+静态断言（hack式写法） #

如果你特别想避免模板，可以用静态断言配合类型检查实现类似效果，但这种写法不如CRTP优雅：

#include <type_traits>

class Base {
public:
    void bar() {
        // 编译期禁止直接实例化Base或用Base指针调用
        static_assert(!std::is_same_v<std::decay_t<decltype(*this)>, Base>, 
                      "Base cannot be used directly");
        // 强制派生类实现foo，否则编译报错
        static_cast<decltype(*this)*>(this)->foo();
    }
};

class Derived1 : public Base {
private:
    void foo() { /* 自定义实现 */ }
    friend class Base;
};

不过这种写法有局限性，比如无法像CRTP一样自动约束派生类必须实现foo，只能在调用bar时才触发编译错误，不如CRTP直观。

静态多态与运行时多态真的无法统一吗？ #

其实两者的核心差异是绑定时机，这直接决定了它们的适用场景：

• 运行时多态适合需要在运行时动态切换类型的场景（比如插件系统、多态容器），哪怕付出一点性能代价。
• 静态多态适合编译期就能确定所有类型的场景，追求极致性能。

虽然代码结构看起来相似，但底层实现和适用场景完全不同。C作为一门兼顾性能和灵活性的语言，选择了分别提供两种特性，而不是强行统一——因为强行统一要么会牺牲静态多态的性能，要么会丢失运行时多态的灵活性，这不符合C的设计理念。

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