实际上:如果派生类中没有任何数据成员，就不会有任何问题，甚至在多态使用中也不会。只有在基类和派生类的大小不同和/或有虚函数(即v-table)时，才需要虚析构函数。

但在理论上:来自c++ 0x FCD中的[expr.delete]:在第一个替代方案(删除对象)中，如果要删除的对象的静态类型与其动态类型不同，则静态类型应是要删除的对象的动态类型的基类，并且静态类型应具有虚析构函数或行为未定义。

但是你可以从std::vector中私有地派生而没有问题。 我使用了以下模式:

class PointVector : private std::vector<PointType>
{
    typedef std::vector<PointType> Vector;
    ...
    using Vector::at;
    using Vector::clear;
    using Vector::iterator;
    using Vector::const_iterator;
    using Vector::begin;
    using Vector::end;
    using Vector::cbegin;
    using Vector::cend;
    using Vector::crbegin;
    using Vector::crend;
    using Vector::empty;
    using Vector::size;
    using Vector::reserve;
    using Vector::operator[];
    using Vector::assign;
    using Vector::insert;
    using Vector::erase;
    using Vector::front;
    using Vector::back;
    using Vector::push_back;
    using Vector::pop_back;
    using Vector::resize;
    ...

如果你正在考虑这个问题，那么你显然已经把办公室里的语言书呆子都干掉了。有了他们，为什么不直接做呢

struct MyVector
{
   std::vector<Thingy> v;  // public!
   void func1( ... ) ; // and so on
}

这将避免所有可能出现的错误，可能会意外地向上转换你的MyVector类，你仍然可以访问所有的向量操作，只需添加一个小.v。

这个问题肯定会让人紧张得喘不过气来，但事实上，没有理由避免从标准容器派生，或者“不必要地增加实体”。最简单、最短的表达是最清晰、最好的。

您确实需要对任何派生类型进行所有通常的注意，但对于来自标准的基类型的情况并没有什么特别之处。重写base成员函数可能很棘手，但对于任何非虚基来说都是不明智的，因此这里没有太多特别之处。如果要添加一个数据成员，如果该成员必须与基库的内容保持一致，则需要考虑切片问题，但这同样适用于任何基库。

The place where I have found deriving from a standard container particularly useful is to add a single constructor that does precisely the initialization needed, with no chance of confusion or hijacking by other constructors. (I'm looking at you, initialization_list constructors!) Then, you can freely use the resulting object, sliced -- pass it by reference to something expecting the base, move from it to an instance of the base, what have you. There are no edge cases to worry about, unless it would bother you to bind a template argument to the derived class.

在c++ 20中，这种技术将立即发挥作用的地方是预留。我们可能在哪里写过

  std::vector<T> names; names.reserve(1000);

我们可以说

  template<typename C> 
  struct reserve_in : C { 
    reserve_in(std::size_t n) { this->reserve(n); }
  };

然后，即使作为班级成员，

  . . .
  reserve_in<std::vector<T>> taken_names{1000};  // 1
  std::vector<T> given_names{reserve_in<std::vector<T>>{1000}}; // 2
  . . .

(根据首选项)，而不需要编写构造函数来调用reserve()。

(The reason that reserve_in, technically, needs to wait for C++20 is that prior Standards don't require the capacity of an empty vector to be preserved across moves. That is acknowledged as an oversight, and can reasonably be expected to be fixed as a defect in time for '20. We can also expect the fix to be, effectively, backdated to previous Standards, because all existing implementations actually do preserve capacity across moves; the Standards just haven't required it. The eager can safely jump the gun -- reserving is almost always just an optimization anyway.)

有些人会认为，reserve_in的情况最好由一个免费的函数模板来实现:

  template<typename C> 
  auto reserve_in(std::size_t n) { C c; c.reserve(n); return c; }

这样的替代方案当然是可行的——有时甚至会因为RVO而快得无限大。但是推导或自由函数的选择应该根据其本身的优点，而不是根据对从标准组件推导的毫无根据的迷信。在上面的例子中，只有第二种形式可以使用free函数;尽管在类上下文之外，它可以写得更简洁一点:

  auto given_names{reserve_in<std::vector<T>>(1000)}; // 2

实际上，std::vector的公共继承并没有什么问题。如果你需要这个，就去做那个。

我建议只有在确实有必要的时候才这样做。只有当你不能用自由函数做你想做的事情时(例如，应该保持一些状态)。

问题是MyVector是一个新实体。这意味着一个新的c++开发人员在使用它之前应该知道它到底是什么。std::vector和MyVector之间的区别是什么?哪一个更适合在这里和那里使用?如果我需要移动std::vector到MyVector怎么办?我可以只用swap()吗?

不要仅仅为了让某些东西看起来更好而创造新的实体。这些实体(尤其是如此常见的实体)不会生活在真空中。它们将生活在熵不断增加的混合环境中。

整个STL被设计成算法和容器是分开的。

这就产生了不同类型迭代器的概念:const迭代器、随机访问迭代器等等。

因此，我建议你接受这个约定，并以这样的方式设计你的算法，即它们不会关心它们正在处理的容器是什么——它们只需要特定类型的迭代器来执行它们的操作。

另外，让我把你引向杰夫·阿特伍德的一些精彩评论。

There is no reason to inherit from std::vector unless one wants to make a class that works differently than std::vector, because it handles in its own way the hidden details of std::vector's definition, or unless one has ideological reasons to use the objects of such class in place of std::vector's ones. However, the creators of the standard on C++ did not provide std::vector with any interface (in the form of protected members) that such inherited class could take advantage of in order to improve the vector in a specific way. Indeed, they had no way to think of any specific aspect that might need extension or fine-tune additional implementation, so they did not need to think of providing any such interface for any purpose.

The reasons for the second option can be only ideological, because std::vectors are not polymorphic, and otherwise there is no difference whether you expose std::vector's public interface via public inheritance or via public membership. (Suppose you need to keep some state in your object so you cannot get away with free functions). On a less sound note and from the ideological point of view, it appears that std::vectors are a kind of "simple idea", so any complexity in the form of objects of different possible classes in their place ideologically makes no use.