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

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

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

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

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

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

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

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

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

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

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

如果你遵循好的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中获取的任何内容。

是的，它是安全的，只要你小心不做不安全的事情……我想我从来没有见过有人用向量new，所以在实践中你可能没问题。然而，这并不是c++....中的常用习语

你能提供更多关于算法的信息吗?

有时你在设计上走了一条路，然后看不到你可能走的其他道路——你声称需要用10种新算法来做矢量，这一事实给我敲响了警钟——矢量真的可以实现10种通用算法吗?或者你试图做一个对象，它既是通用矢量，又包含特定的应用程序功能?

我当然不是说你不应该这样做，只是你所提供的信息敲响了警钟，这让我认为也许你的抽象是有问题的，有更好的方法来实现你想要的。

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.