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)

APPEND：

问：为什么我不把代码嵌入到课堂内？

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

有时我们甚至不需要从宏生成的类中获取任何成员，但该类必须包含成员才能提供某些功能（例如navigationController一些辅助类模板）。
不允许对嵌套类模板进行完全特化，这使我无法使用嵌套类来避免2）中提到的名称空间冲突。

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

Answer 1

因为Bjarne（20世纪80年代）和ISO委员会（20世纪90年代）都没有人认识到这一点。直到今天这个宏观的hackery，我才真正想到它。

以下是语言的开发方式：

一无所知
需要功能吗？加吧！

以下是语言不开发的方式：

以∞页长标准
不需要功能？删除它！

Answer 2

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

你将CONTENT放在哪里，只会在课程MyClass中使用或甚至可以访问，所以它同样可以写在HERE所在的位置。

如果你想＆＃34;组织＆＃34;单个类的内容，你可以使用＆＃34;嵌套＆＃34;用于增强封装的类：

class Thing {
  class SomeSubThing {} subthing;
};

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

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

2 个答案: