c++ - gcc4.9.2的std::vector的libstdc++实现继承自_Vector_base(非虚拟析构函数)。为什么这样可以？

Question

This question already has answers here:

Thou shalt not inherit from std::vector

(13个回答)


6年前关闭。




所以一段时间以来，我一直在使用从std::vector派生的容器。也许由于几个原因，这是一个糟糕的设计决策，并且在此处广泛讨论了是否应该这样做的问题:

Thou shalt not inherit from std::vector

Subclass/inherit standard containers?

Is there any real risk to deriving from the C++ STL containers?

Is it okay to inherit implementation from STL containers, rather than delegate?

我确定我错过了一些讨论……但是在链接中可以找到两种观点的合理论点。据我所知，“因为〜vector()是非虚拟的”是您不应从STL容器继承的“规则”的基础。但是，如果看一下g++ 4.9.2中std::vector的实现，我发现std::vector继承自_Vector_base，而_Vector_base是非虚拟析构函数。

template<typename _Tp, typename _Alloc = std::allocator<_Tp> >
class vector : protected _Vector_base<_Tp, _Alloc>
{
...
  ~vector() _GLIBCXX_NOEXCEPT
  { std::_Destroy(this->_M_impl._M_start, this->_M_impl._M_finish,
    _M_get_Tp_allocator()); }

...
}

哪里:

template<typename _Tp, typename _Alloc>
struct _Vector_base
{
...
  ~_Vector_base() _GLIBCXX_NOEXCEPT
  { _M_deallocate(this->_M_impl._M_start, this->_M_impl._M_end_of_storage
    - this->_M_impl._M_start); }

...
}

因此，gcc 4.9.2实现的std::vector从具有非虚拟析构函数的基类继承。这使我相信这是可以接受的做法。为什么这样可以？这种做法不构成危险的具体条件是什么？

最佳答案

1:std::vector不继承自_Vector_base
或者说，不是在我的标准库实现中。 libc++实现 vector 是这样的:

namespace std
{

template <class T, class Allocator = allocator<T> >
class vector
{
...

当然，您的实现可能继承自基类，但我的实现却没有。这导致您对“规则”的解释出现第一个错误:

C++标准库可以通过多种方式实现，我们真的不能从odt_strong标准库(由 ISO/IEC 14882:2014定义的那个库)的一种实现中做出广泛而广泛的假设或声明。

因此，在进一步了解之前，请记住:在此答案中，我们将不着重于单个实现。我们将考虑所有实现(通过关注C++标准中的定义；而不是硬盘驱动器上特定头文件的定义)。

2:是的，所以 std::vector继承自 _Vector_base
但是在继续之前，让我们承认您的实现可能继承自 _Vector_base，这没关系。那么，为什么允许 std::vector从基类继承，却又不允许您从 std::vector继承？

3:如果需要，可以从 std::vector继承(请注意)

出于可以从 std::vector继承的相同原因， _Vector_base可以从 std::vector继承:库实现者非常小心(您也应该如此)。
std::vector不是 delete指针多态的 _Vector_base d。因此，我们不必担心 ~vector()不是虚拟的。如果您不使用多态 delete指针对继承的类进行 std::vector编码，则非虚拟的 ~vector()并非问题。没关系。别担心。让我们不要大惊小怪。没有多态的 delete意味着我们不必担心析构函数是否是虚拟的。

但是除此之外，库实现者还通过使用 std::vector引用来确保 _Vector_base绝不是 sliced。对您来说也一样:如果可以确保您的自定义 vector 类不会被切片(使用 std::vector引用的人)，那么在这里也可以。没有切片意味着我们不必担心会产生不良副本。

4:为什么不应该从 std::vector继承

这在其他问题上已经得到了很多回答，但是我将在这里再说一遍(并以整个 _Vector_base继承问题为重点):您(可能)不应从 std::vector继承。

问题是，如果这样做，则使用自定义 vector 类的某人可能会对其进行多态删除(他们可能具有指向它的 std::vector指针和 delete的指针，如果这样做的话，这是一件不好的事情)。或者他们可能有一个指向您的自定义对象的 std::vector引用，并尝试对其进行复制(这将对该对象进行切片，这也可能是一件坏事)(我一直假设需要使用一个指向您的自定义对象的 std::vector引用来导致复制时进行对象切片，因为我一直假设您足够小心，以至于永远不会意外地用 careless assignment或 function call切片对象；我敢肯定，您永远不会如此粗心，但是其他使用 std::vector引用的人可能是(和是的，我在这里有点滑稽))。

您可以控制对代码的处理。而且，如果可以(仔细)控制它以确保没有多态的 delete或对象切片，那么您就可以了。

但是有时您无法真正控制其他人对您的代码的处理。如果您在团队中工作，那么如果一个团队成员不经意间执行了其中一项操作，则可能会出现问题。这就是为什么我一直提起“小心”的原因。

更糟糕的是，如果您的代码被客户端使用，您实际上就无法控制他们的工作，并且如果他们做这些坏事之一，您可能就是应该责怪并负责修复它的人(重构过去曾经依赖于自定义类继承自 std::vector的所有代码的乐趣)(或者只是告诉客户端他们不能这样做，但是您可能会有一个脾气暴躁的客户端，他们浪费时间调试他们没有解决的奇怪问题)希望会遇到)。

但是，您的C++标准库实现者可以摆脱这种继承，因为他们可以很好地控制事物:不允许任何人使用 _Vector_base。您可以使用 std::vector。仅 std::vector。由于不允许(永远)使用 _Vector_base，因此标准库实现者不必担心对象切片或多态 delete。而且由于他们在受控环境中执行时非常小心，因此一切正常。

但是更好的是，通过不对 std::vector的实现方式进行假设，而是将其视为(有用的)黑盒，我们可以确保我们如何使用 std::vector可以移植到其他标准库实现中。如果您假设从某个基类继承了 std::vector，则将限制代码的可移植性。

关于c++ - gcc4.9.2的std::vector的libstdc++实现继承自_Vector_base(非虚拟析构函数)。为什么这样可以？ ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27334801/

上一篇：c++ - 无法将临时对象作为引用传递

下一篇：c++ - 从 listWidget 中删除选定的项目

Answer 1

1:std::vector不继承自_Vector_base
或者说，不是在我的标准库实现中。 libc++实现 vector 是这样的:

namespace std
{

template <class T, class Allocator = allocator<T> >
class vector
{
...

当然，您的实现可能继承自基类，但我的实现却没有。这导致您对“规则”的解释出现第一个错误:

C++标准库可以通过多种方式实现，我们真的不能从odt_strong标准库(由 ISO/IEC 14882:2014定义的那个库)的一种实现中做出广泛而广泛的假设或声明。

因此，在进一步了解之前，请记住:在此答案中，我们将不着重于单个实现。我们将考虑所有实现(通过关注C++标准中的定义；而不是硬盘驱动器上特定头文件的定义)。

2:是的，所以 std::vector继承自 _Vector_base
但是在继续之前，让我们承认您的实现可能继承自 _Vector_base，这没关系。那么，为什么允许 std::vector从基类继承，却又不允许您从 std::vector继承？

3:如果需要，可以从 std::vector继承(请注意)

出于可以从 std::vector继承的相同原因， _Vector_base可以从 std::vector继承:库实现者非常小心(您也应该如此)。
std::vector不是 delete指针多态的 _Vector_base d。因此，我们不必担心 ~vector()不是虚拟的。如果您不使用多态 delete指针对继承的类进行 std::vector编码，则非虚拟的 ~vector()并非问题。没关系。别担心。让我们不要大惊小怪。没有多态的 delete意味着我们不必担心析构函数是否是虚拟的。

但是除此之外，库实现者还通过使用 std::vector引用来确保 _Vector_base绝不是 sliced。对您来说也一样:如果可以确保您的自定义 vector 类不会被切片(使用 std::vector引用的人)，那么在这里也可以。没有切片意味着我们不必担心会产生不良副本。

4:为什么不应该从 std::vector继承

这在其他问题上已经得到了很多回答，但是我将在这里再说一遍(并以整个 _Vector_base继承问题为重点):您(可能)不应从 std::vector继承。

问题是，如果这样做，则使用自定义 vector 类的某人可能会对其进行多态删除(他们可能具有指向它的 std::vector指针和 delete的指针，如果这样做的话，这是一件不好的事情)。或者他们可能有一个指向您的自定义对象的 std::vector引用，并尝试对其进行复制(这将对该对象进行切片，这也可能是一件坏事)(我一直假设需要使用一个指向您的自定义对象的 std::vector引用来导致复制时进行对象切片，因为我一直假设您足够小心，以至于永远不会意外地用 careless assignment或 function call切片对象；我敢肯定，您永远不会如此粗心，但是其他使用 std::vector引用的人可能是(和是的，我在这里有点滑稽))。

您可以控制对代码的处理。而且，如果可以(仔细)控制它以确保没有多态的 delete或对象切片，那么您就可以了。

但是有时您无法真正控制其他人对您的代码的处理。如果您在团队中工作，那么如果一个团队成员不经意间执行了其中一项操作，则可能会出现问题。这就是为什么我一直提起“小心”的原因。

更糟糕的是，如果您的代码被客户端使用，您实际上就无法控制他们的工作，并且如果他们做这些坏事之一，您可能就是应该责怪并负责修复它的人(重构过去曾经依赖于自定义类继承自 std::vector的所有代码的乐趣)(或者只是告诉客户端他们不能这样做，但是您可能会有一个脾气暴躁的客户端，他们浪费时间调试他们没有解决的奇怪问题)希望会遇到)。

但是，您的C++标准库实现者可以摆脱这种继承，因为他们可以很好地控制事物:不允许任何人使用 _Vector_base。您可以使用 std::vector。仅 std::vector。由于不允许(永远)使用 _Vector_base，因此标准库实现者不必担心对象切片或多态 delete。而且由于他们在受控环境中执行时非常小心，因此一切正常。

但是更好的是，通过不对 std::vector的实现方式进行假设，而是将其视为(有用的)黑盒，我们可以确保我们如何使用 std::vector可以移植到其他标准库实现中。如果您假设从某个基类继承了 std::vector，则将限制代码的可移植性。