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

您确实需要对任何派生类型进行所有通常的注意，但对于来自标准的基类型的情况并没有什么特别之处。重写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，发现它非常有用，到目前为止我还没有遇到任何问题。

我的类是一个稀疏矩阵类，这意味着我需要在某个地方存储我的矩阵元素，即在std::vector中。我继承的原因是我有点太懒了，不愿意为所有的方法编写接口，而且我正在通过SWIG将类接口到Python，其中已经有std::vector的良好接口代码。我发现将这个接口代码扩展到我的类中要比从头开始编写一个新代码容易得多。

这种方法的唯一问题不是非虚析构函数，而是一些我想重载的其他方法，比如push_back()、resize()、insert()等。私人继承的确是一个不错的选择。

谢谢!

我认为很少有规则是应该百分之百地盲从的。听起来你已经考虑了很多，并且相信这是一条正确的道路。所以——除非有人提出很好的具体理由不这样做——我认为你应该继续你的计划。

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

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

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

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

你希望完成什么?只是提供一些功能?

c++惯用的方法是编写一些实现该功能的自由函数。有可能您实际上并不需要std::vector，特别是对于您正在实现的功能，这意味着您实际上通过尝试继承std::vector而失去了可重用性。

我强烈建议您查看标准库和标头，并思考它们是如何工作的。

如果你遵循好的c++风格，缺少虚函数不是问题，而是切片(参见https://stackoverflow.com/a/14461532/877329)

为什么虚函数的缺失不是问题?因为函数不应该尝试删除它接收到的任何指针，因为它没有指针的所有权。因此，如果遵循严格的所有权策略，就不应该需要虚拟析构函数。例如，这总是错误的(有或没有虚析构函数):

void foo(SomeType* obj)
    {
    if(obj!=nullptr) //The function prototype only makes sense if parameter is optional
        {
        obj->doStuff();
        }
    delete obj;
    }

class SpecialSomeType:public SomeType
    {
    // whatever 
    };

int main()
    {
    SpecialSomeType obj;
    doStuff(&obj); //Will crash here. But caller does not know that
//  ...
    }

相反，这将始终工作(使用或不使用虚析构函数):

void foo(SomeType* obj)
    {
    if(obj!=nullptr) //The function prototype only makes sense if parameter is optional
        {
        obj->doStuff();
        }
    }

class SpecialSomeType:public SomeType
    {
    // whatever 
    };

int main()
    {
    SpecialSomeType obj;
    doStuff(&obj);
//  The correct destructor *will* be called here.
    }

如果该对象是由工厂创建的，工厂还应该返回一个指向工作删除器的指针，应该使用该指针而不是delete，因为工厂可能使用自己的堆。调用者可以以share_ptr或unique_ptr的形式获取它。简而言之，不要删除不是直接从new中获取的任何内容。