我一直在想，C++ 中的设计决定是否有任何理由不为任何 std 库容器提供纯抽象类？
我很欣赏 hash_map 后来来自 stdext 命名空间，但共享一个非常相似的接口。如果我后来决定要为特定的软件实现自己的地图，我宁愿有某种接口可以使用。
例子
std::base_map *foo = new std::map<std::string, std::string>;
delete foo;
foo = new stdext::hash_map<std::string, std::string>;
显然，据我所知，上面的示例是不可能的，但是对于 list 和其他 std lib 容器来说，这是类似的。
我很欣赏这不是 C# 或 Java，但是 C++ 中显然没有限制来阻止这种设计，那么为什么要这样设计，以便类似容器之间没有耦合。
因为虚函数会增加开销。
因为容器并不都有相同的接口，所以有一些共同的功能，但在迭代器失效和内存分配（以及异常行为）方面也存在重要差异，如果您使用的是抽象基础，您将不会知道具体容器如何表现的细节。
如果您想编写与传递的容器类型无关的代码，那么在 C++ 中您编写模板而不是依赖抽象接口，即使用静态多态而不是动态多态。这避免了动态调度的开销，并且还允许基于具体类型的专门化，因为具体类型在编译时是已知的。
最后，恕我直言，它没有任何优势。它是更好的方式。正如您所说，谢天谢地，这不是 C# 或 Java。
（PS stdext 命名空间不是 C++ 的一部分，它似乎是 Microsoft 的非标准类型命名空间，一个更好的例子是使用std::tr1::unordered_maporstd::unordered_map代替stdext::hash_map）