shared_ptr 析构函数，复制和不完整类型

Question

我有一个像这样的头文件foo.h（不相关的东西省略了）：

#pragma once
#include <memory>

class Bar;


struct Foo
{
  std::shared_ptr<Bar> getBar();

  std::shared_ptr<const Bar> getBar() const
  {
    return const_cast<Foo*>(this)->getBar();
  }
};

getBar() 的非常量重载在一个 .cpp 文件中实现，该文件还可以看到 Bar 的完整定义。

当foo.h 包含在另一个文件中（没有看到Bar 的定义）时，VS 2010 会给出这样的警告：

warning C4150: deletion of pointer to incomplete type 'Bar'; no destructor called

getBar() 的 const 重载（或者实际上是从该重载实例化的标准库深处的某些东西）。

我的问题是是否可以安全地忽略该警告。

在我看来，std::shared_ptr<Bar> 的两个成员函数在getBar() const 中被调用：转换构造函数和析构函数。

// converting constructor
template <class Y>
std::shared_ptr<const Bar>::shared_ptr(std::shared_ptr<Y> &&r)

这用于从getBar()的返回值初始化getBar() const的返回值。这没有列出任何需要Y（在我的情况下为Bar）才能完成的先决条件（C++11 27.2.2.1 §20-22）。

// destructor
std::shared_ptr<const Bar>::~shared_ptr()

27.2.2.2 §1 规定当被销毁的共享指针为空时，没有副作用。

我理解为什么我会收到警告 - 析构函数代码还必须注意必须在存储的指针上调用 delete 的情况，并且此代码确实会删除不完整的类型。但在我看来，在我的情况下永远无法达到，所以getBar() const 是安全的。

我是正确的，还是我忽略了一个电话或其他可能使getBar() const 实际上删除不完整类型的东西？

Answer 1

我找不到警告的理由。我也不能用 clang/libc++ 复制警告。

一般来说，给定一个shared_ptr<Bar>，如果没有看到采用Bar* 的shared_ptr<Bar> 的构造以及可选的删除器，就无法确定~Bar() 是否是ever 调用。没有办法知道shared_ptr<Bar> 中存储了什么删除器，并且给定一些未知的删除器d 存储在shared_ptr<Bar> 中，在Bar* 旁边（比如p），没有要求d(p) 调用~Bar()。

例如，您的Bar 可能没有可访问的析构函数：

class Bar
{
    ~Bar();
};

您的Foo::getBar() 可以这样实现：

std::shared_ptr<Bar>
Foo::getBar()
{
    // purposefully leak the Bar because you can't call ~Bar()
    return std::shared_ptr<Bar>(new Bar, [](Bar*){});
}

编译器不看 foo.cpp 就无法知道。

这个警告在我看来像是一个编译器错误，或者可能是 std::shared_ptr 的实现中的错误。

你能忽略这个警告吗？我不知道。在我看来，您正在处理实现中的错误，因此该错误很可能意味着警告是真实的。但是假设一个完全符合的实现，我认为Bar 不需要在您显示的代码中是一个完整的类型。

Answer 2

没有；不能安全地忽略该警告。您的代码创建了一个 shared_ptr 对象。 shared_ptr 构造函数是创建和存储删除器的模板。通过在标头中添加代码来创建 shared_ptr，您最终会过早地实例化模板构造函数。

shared_ptr 使用的删除器技巧允许你在定义类之前声明它们，但它们仍然需要在你第一次使用它们之前查看完整的类型。您的代码永远无法保证调用 Bar 的析构函数。更糟糕的是，今天它甚至可以工作，但可能是一个定时炸弹，使您的代码中出现一个非常难以调试的错误。

问题与代码中指针的内容无关。只要您有创建共享指针的代码，它没有看到 Bar 的完整定义，这一事实就足够了。

修复很简单。只需将该代码放入您的实现文件中，在 Bar 的完整声明之后。

编辑：g++ 给出的警告适合这种情况，但代码不适合。现在我将保留这个答案，直到我有时间调查（或者其他人弄清楚为什么 g++ 会给出这个警告）。