为什么我们不能为继承定义一个匿名类？

Question

class MyClass : SomeFeatureGeneratedByTemplate<MyClass>

通过继承实例化的类模板,模板为我们的类添加功能提供了很多便利.

但是,有时该功能可能变得太复杂而无法通过模板实现,其中宏可能是唯一的选择.

    MACRO_TO_GENERATE_COMPLICATED_FEATURE(MyClass) 
   /* Might be expanded to 
    #ifndef MYCLASS_FEATURE_CLASS
    #define MYCLASS_FEATURE_CLASS
        class MyClassFeature { ... };
    #endif
   */
   class MyClass : MyClassFeature 

我想知道以下语法是否会简化这一点:允许在适当的位置定义一个匿名类

class MyClass : class { ... }, class{ ... }

因此,上面的代码可以重写为:

class MyClass : MACRO_GEN_FEATURE(MyClass)

附加:

问:为什么我不把代码嵌入到类中？

答:1.此功能应明确并向用户公开.当他们生成docs时,派生类很容易被发现:class A: FEATURE1(A), FEATURE2(A)而嵌入式宏则不容易发现.虽然可以推导出一个空类来实现我们的目标(例如class A: FEATURE1(A)//just derive predefined struct FEATURE1_EMPTY{};),但显然它不是一个完美的解决方案.

2. 有时我们甚至不需要从宏生成的类中获取任何成员,但该类必须包含成员以提供一些函数(例如,static_assert使用一些帮助器类模板).

3. 不允许完全专门化嵌套类模板,这使我无法使用嵌套类来避免2)中提到的命名空间冲突.

我知道这现在是非法的,但为什么在C++标准中不允许这样做？

Answer 1

因为Bjarne(20世纪80年代)和ISO委员会(20世纪90年代)都没有人认识到这一点.在今天这个宏观的hackery之前,我从未见过需要它.

以下是语言的开发方式:

• 一无所获
• 功能是否需要？加吧!

下面是一个语言不发展:

• 从∞页长标准开始,每个可能的功能
• 功能不需要？去掉它!

Answer 2

class MyClass : class { /* CONTENT */ } {
  // HERE
};

什么你会把它放在哪里CONTENT,只会在课堂上使用或甚至可以访问MyClass,所以它同样可以写在HERE看台上.

如果要"组织"单个类的内容,可以使用"嵌套"类来增强封装:

class Thing {
  class SomeSubThing {} subthing;
};

虽然这有用甚至可推荐是否高度依赖于实际情况并且可能非常主观.