您不应该继承std :: vector

好的，这确实很难让人承认，但是目前我确实有很强的诱惑力可以继承std::vector。

我需要大约10种针对矢量的自定义算法，并且希望它们直接成为矢量的成员。但是我自然也希望拥有的其余std::vector界面。好吧，作为守法公民，我的第一个想法是std::vectorMyVector班级成员。但是然后我将不得不手动重新提供所有std :: vector的接口。输入太多。接下来，我考虑了私有继承，因此我将using std::vector::member在公共部分写一堆，而不是提供方法。其实这也很乏味。

在这里，我确实确实认为我可以简单地从公开继承std::vector，但是在文档中提供警告，该类不应被多态使用。我认为大多数开发人员都有足够的能力来理解，无论如何都不应多态地使用它。

我的决定绝对不合理吗？如果是这样，为什么？您能否提供一种替代方法，使其他成员实际成为成员，而不涉及重新键入vector接口的所有内容？我对此表示怀疑，但如果可以的话，我会很高兴。

此外，除了一些白痴可以写类似的事实

std::vector<int>* p  = new MyVector

使用MyVector 还有其他现实的危险吗？通过说现实，我舍弃了像想象一个需要指向矢量指针的函数之类的事情。

好吧，我已经说了我的案子。我犯罪了。现在由你来原谅我:)

实际上，公共继承没有错 std::vector。如果需要此功能，请执行此操作。

我建议只有在确实必要时。仅当您无法使用自由函数做您想做的事情时（例如，应保持某种状态）。

问题在于这MyVector是一个新实体。这意味着新的C ++开发人员在使用它之前应该知道它到底是什么。std::vector和之间有什么区别MyVector？在这里和那里使用哪个更好？如果我需要搬到std::vector该MyVector怎么办？我可以用吗swap()还是不？

不要仅仅为了使外观变得更好而产生新的实体。这些实体（尤其是这样的实体）不会存在真空中。它们将生活在熵不断增加的混合环境中。

整个STL的设计方式使算法和容器是分开的。

这导致了不同类型的迭代器的概念：常量迭代器，随机访问迭代器等。

因此，我建议您接受此约定并以这样的方式设计算法，使他们不必关心正在使用的容器是什么并且它们只需要执行其操作所需的特定类型的迭代器即可。操作。

另外，让我将您引向Jeff Attwood的一些评价。

不std::vector公开继承的主要原因是缺少虚拟析构函数，该析构函数有效地防止了您对子代进行多态使用。特别是，你都不准到delete一个std::vector<T>*在派生类对象（即使在派生类中没有增加成员），实际点，但编译器一般不能向您发出警告。

在这些条件下允许私有继承。因此，我建议使用私有继承并从父级转发必需的方法，如下所示。

class AdVector: private std::vector<double>
{
    typedef double T;
    typedef std::vector<double> vector;
public:
    using vector::push_back;
    using vector::operator[];
    using vector::begin;
    using vector::end;
    AdVector operator*(const AdVector & ) const;
    AdVector operator+(const AdVector & ) const;
    AdVector();
    virtual ~AdVector();
};

正如大多数答复者所指出的那样，您应该首先考虑重构算法以抽象化它们正在操作的容器的类型，并将其保留为免费的模板化函数。通常通过使算法接受一对迭代器而不是容器作为参数来完成此操作。

如果您正在考虑这一点，那么您显然已经杀害了办公室中的语言学习者。把他们挡在门外，为什么不做

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

这将避免因意外上载MyVector类而引起的所有可能的错误，并且您仍然可以通过添加一点来访问所有矢量操作.v。

您希望完成什么？只是提供一些功能？

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

我强烈建议您查看标准库和标头，并沉思它们的工作方式。

我认为很少有100％的时间应该盲目遵循规则。听起来您已经考虑了很多，并确信这是要走的路。所以-除非有人提出了明确的特定理由不这样做，否则我认为您应该继续执行您的计划。

没有理由要继承，std::vector除非有人希望创建一个类，其工作方式不同于std::vector，因为它以自己的方式处理std::vector的定义的隐藏细节，或者除非出于意识形态的原因要使用此类的对象代替std::vector的。但是，C ++标准的创建者没有提供std::vector任何接口（以受保护成员的形式），此类继承的类可以利用该接口来以特定方式改进向量。实际上，他们没有办法考虑可能需要扩展或微调其他实现的任何特定方面，因此他们无需考虑出于任何目的提供任何此类接口。

第二种选择的原因仅仅是出于意识形态，因为std::vectors不是多态的，否则，无论是std::vector通过公共继承还是通过公共成员身份公开的公共接口，都没有区别。（假设您需要在对象中保留一些状态，以使您无法摆脱自由功能）。从意识形态的角度来看，从一个不太合理的角度来看，看来std::vectors是一种“简单的想法”，因此，在意识形态上不同可能类别的对象形式的任何复杂性在意识形态上都没有用。

实际上：如果您的派生类中没有任何数据成员，则不会有任何问题，甚至在多态用法上也不会有问题。仅当基类和派生类的大小不同和/或具有虚拟函数（即v表）时，才需要虚拟析构函数。

但从理论上讲：从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;
    ...

如果遵循良好的C ++风格，则缺少虚函数不是问题，而是切片（请参见 https://stackoverflow.com/a/14461532/877329）

为什么没有虚拟功能不是问题？因为函数不应该尝试获取delete它的任何指针，因为它没有它的所有权。因此，如果遵循严格的所有权策略，则不需要虚拟析构函数。例如，这总是错误的（使用或不使用虚拟析构函数）：

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。简而言之，不要直接从中delete得到任何东西。new

是的，只要您小心不要做不安全的事情，它就是安全的。我认为我从未见过有人使用带有new的向量，因此在实践中您会没事的。但是，这不是c ++中的常见用法。

您能否提供有关算法是什么的更多信息？

有时，您最终在设计上走了一条路，却看不到您可能走过的另一条路-您声称需要使用10种新算法进行导航的事实为我敲响了警钟-实际上有10个通用用途向量可以实现的算法，或者您是否试图创建既是通用向量又包含特定于应用程序功能的对象？

我当然不是在说您不应该这样做，只是因为您所提供的信息已经响起了警钟，这让我认为您的抽象也许出了点问题，并且有更好的方法来实现您的目标想。

我也是从std::vector最近继承过来的，并发现它非常有用，到目前为止，我还没有遇到任何问题。

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

我可以用这种方法看到的唯一的问题是没有这么多与非虚析构函数，而是一些其他的方法，我想超载，如push_back()，resize()，insert()等私有继承确实可以成为一个不错的选择。

谢谢！

在这里，让我介绍两种您想要的方式。一种是包装的std::vector另一种方式，另一种是不给用户机会破坏任何东西的继承方式：

1. 让我添加另一种包装方式，std::vector而无需编写很多函数包装器。

#include <utility> // For std:: forward
struct Derived: protected std::vector<T> {
    // Anything...
    using underlying_t = std::vector<T>;

    auto* get_underlying() noexcept
    {
        return static_cast<underlying_t*>(this);
    }
    auto* get_underlying() const noexcept
    {
        return static_cast<underlying_t*>(this);
    }

    template <class Ret, class ...Args>
    auto apply_to_underlying_class(Ret (*underlying_t::member_f)(Args...), Args &&...args)
    {
        return (get_underlying()->*member_f)(std::forward<Args>(args)...);
    }
};

2. 继承自std :: span而不是std::vectordtor问题。

这个问题肯定会引起喘不过气来，但实际上并没有正当理由避免或“不必要地增加实体”来避免从标准容器中派生。最简单，最短的表达方式是最清晰，最好的。

您确实需要对所有派生类型进行所有常规维护，但是对于标准的基本情况并没有什么特别的。覆盖基本成员函数可能很棘手，但是对任何非虚拟基本成员来说这都是不明智的，因此这里没有太多特殊之处。如果要添加数据成员，则必须担心切片，如果该成员必须与基本内容保持一致，但是对于任何基本而言，这也是相同的。

我发现从标准容器派生的地方特别有用，是添加一个可以精确执行所需初始化的构造函数，而不会引起其他构造函数的混乱或劫持。（我正在看你的initialize_list构造函数！）然后，您可以自由地使用切片后的结果对象-通过引用将其传递给需要基础的对象，然后从该对象移至基础的实例，您拥有什么。无需担心任何极端情况，除非它会打扰您将模板参数绑定到派生类。

在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（）。

（从reserve_in技术上来说，需要等待C ++ 20的原因是，先前的标准不需要跨步保留空向量的容量。这被认为是疏忽，可以合理地预期会得到修复。作为20年代及时的缺陷。我们还可以期望该修补程序可以有效地追溯到以前的标准，因为所有现有的实现实际上都保留了跨移动的能力；这些标准并不需要它。枪-无论如何，保留几乎总是一种优化。）

有人认为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