简单地说，做和说之间有什么区别

VS

我能想到的唯一优势(以及它导致我提出这个问题的原因)是，通过派生类，我现在可以很容易地将MyClassList声明为

没有编译器错误，而不是

我想不出有什么不同，但这让我怀疑，是否有一些情况下typedef可以被使用，而简单的派生类不能？

或者换一种说法，我有什么理由不把所有typedef列表<…>someClassList；都改为简单的派生类，这样我就可以轻松地转发声明它们了吗？

在C++中，不建议从STL容器中派生，所以不要这样做。

typedef只是为现有的类型创建一个别名，就像以前一样，所以typedef std::list MyClassList;创建了一个"新类型"，称为MyClassList，您现在可以按如下方式使用：

MyClassList lst;

把你的typedef改成派生类是个坏主意。不要这样做。

typedef正是为了这个目的——别名类型名。它非常地道，不会混淆任何熟悉C++的人。

但要解决为什么继承可能是个坏主意。

std::list没有虚拟析构函数。意味着当通过基类删除时，MyClassList不会调用其析构函数。所以这通常是不允许的。在您的例子中，您不打算将任何成员放入MyClassList中，因此这是一个不确定的点，直到下一个程序员将继承视为添加新成员/重写函数等的邀请为止。他们可能没有意识到std::list的析构函数不是虚拟的，也没有意识到在某些情况下，MyClassList的析构函数不会得到CA。LLED。

好吧，一个typedef只能按照它的名字做，而一个派生类可能是它的基础的全面改造。因此，尽管对于编译器而言，如果您将自己限制为"仅"派生(而不添加任何成员或重写任何内容等)，那么就人类代码读者而言，可能存在很大的差异。

有人可能会想，"当typedef足够时，为什么这是一个派生类？"大多数人都会认为这是有原因的，所以你会使代码未来的维护人员的生活更加困难。另一方面，typedef是一种非常具体的工具，不会提出问题。

当我们谈到维护这个话题的时候，不要忘记，因为C++中的大多数东西，只要我们遵守纪律，不跨越这条线，"没有什么会出错的"是对灾难的公开邀请。因为编译器不在那里阻止你，总有一天，有人会越界的。

typedef是别名，而类是新类型。在第一种情况下，编译器必须简单地用list替换myclasslist。在第二种情况下，MyCaseLead涉及生成默认构造函数、复制构造函数赋值运算符、析构函数，以及在其中使用C++ 11 -甚至移动构造函数和移动赋值。在默认情况下，由于myClassList没有附加功能，因此优化很可能会将它们清除。

注意：我发现"不建议使用非虚拟析构函数派生类"参数是一个弱参数。C++开发人员应该知道派生并不一定意味着多态性。未通过指向其基的指针删除的类不需要虚拟析构函数，就像其方法不是设计为通过基指针"调用"的类不需要该方法是虚拟的。简单地说，如果析构函数不是虚拟的，不要在删除时将该类型视为"多态"。从这个意义上讲，析构函数与其他虚拟或非虚拟方法没有区别。如果必须将此参数视为强参数，则不应派生所有没有"all virtual"方法的类！

已经提到了很多事情。然而，一件大事是：

从类型派生并不继承所有构造函数。

如果有许多非默认的构造函数，则在继承时就不会有它们(必须将它们转发到基本构造函数)。

typedef没有这样的"issue"。

现在，typedef不会生成唯一的typeid。如果您希望这样做，并且没有继承的开销或其他缺点，请看boost：它有一个生成唯一typeid的强typedef宏：

http://www.boost.org/doc/libs/1_37_0/boost/strong_typedef.hpp