c++ - 自动实例化的智能指针

Question

我正在寻找一种减少C++项目中 header 耦合的简单方法，这主要是由于(过度使用的)类组合，这当然需要完整的类型。例如:

// header A
class A
{
  B b; // requires header B
};

我也考虑过接口(interface)和pimpl，但是它们都暗示了一些我不想手动编写/支持的样板代码(或者有没有使之自动的方法？)。

因此，我考虑过用一个指针和一个类似于class B* pB;的转发替换成员，但这需要处理对象的创建和删除。好的，我可以使用智能指针进行删除(虽然不是auto_ptr，因为它在创建时需要完整的类型，所以要说类似shared_ptr<class B> pB;这样的东西)，但是现在如何进行对象创建呢？

我可以在A的构造函数中创建对象，例如pB = new B;，但这又是手动的，更糟糕​​的是，可能有多个构造函数...所以我正在寻找一种自动执行此操作的方法，该方法可以工作就像在B b;的定义中将autoobjptr<class B> pB;更改为A一样简单，而不必费心pB实例化。

我很确定这不是一个新主意，所以也许您可以为我提供常见解决方案或讨论的引用？

更新:为了澄清起见，我没有试图打破A和B之间的依赖关系，但是当一个包含B的 header 时，我想避免包含A的 header 。在实践中，B用于实现A，因此典型的解决方案是为A创建接口(interface)或pimpl，但我目前正在寻找更简单的方法。

UPDATE2:我突然意识到，当与虚拟析构函数结合使用(允许不完整的类型)时，像拟议的here这样的惰性指针可以解决问题(很遗憾，在boost中没有这种标准的实现)。我仍然不明白为什么没有标准的解决方案，并且想重新发明轮子...

UPDATE3:突然，Sergey Tachenov提出了一个非常简单的解决方案(公认的答案)，尽管我花了半个小时才了解它为什么真正起作用...
如果删除A()构造函数或在头文件中内联定义它，那么魔术将不再起作用(出现错误)。我猜想，当您定义显式的非内联构造函数时，成员(甚至隐式成员)的构造在B类型完整的同一编译单元(A.cpp)中完成。另一方面，如果您的A构造函数是内联的，则成员的创建必须在其他编译单元内部进行，并且因为B在此不完整而无法正常工作。好吧，这是合乎逻辑的，但是现在我很好奇-这种行为是由C++标准定义的吗？

UPDATE4:希望最终更新。有关上述问题的讨论，请引用接受的答案和评论。

Answer 1

最初，我对这个问题很感兴趣，因为它看起来确实很棘手，并且所有有关模板，依赖项和包含在内的注释都是有意义的。但是后来我尝试实际实现它，发现它出奇的简单。因此，要么我误解了这个问题，要么这个问题具有一些看起来比实际困难得多的特殊属性。无论如何，这是我的代码。

这是美化的autoptr.h:

#ifndef TESTPQ_AUTOPTR_H
#define TESTPQ_AUTOPTR_H

template<class T> class AutoPtr {
  private:
    T *p;
  public:
    AutoPtr() {p = new T();}
    ~AutoPtr() {delete p;}
    T *operator->() {return p;}
};

#endif // TESTPQ_AUTOPTR_H

看起来真的很简单，我想知道它是否真的有效，所以我为此做了一个测试案例。这是我的生日:

#ifndef TESTPQ_B_H
#define TESTPQ_B_H

class B {
  public:
    B();
    ~B();
    void doSomething();
};

#endif // TESTPQ_B_H

和b.cpp:

#include <stdio.h>
#include "b.h"

B::B()
{
  printf("B::B()\n");
}

B::~B()
{
  printf("B::~B()\n");
}

void B::doSomething()
{
  printf("B does something!\n");
}

现在是实际使用此功能的A类。这是一个小时:

#ifndef TESTPQ_A_H
#define TESTPQ_A_H

#include "autoptr.h"

class B;

class A {
  private:
    AutoPtr<B> b;
  public:
    A();
    ~A();
    void doB();
};

#endif // TESTPQ_A_H

和a.cpp:

#include <stdio.h>
#include "a.h"
#include "b.h"

A::A()
{
  printf("A::A()\n");
}

A::~A()
{
  printf("A::~A()\n");
}

void A::doB()
{
  b->doSomething();
}

好的，最后是使用A但不包含“b.h”的main.cpp:

#include "a.h"

int main()
{
  A a;
  a.doB();
}

现在，它实际上可以编译，没有任何错误或警告，并且可以正常工作:

d:\alqualos\pr\testpq>g++ -c -W -Wall b.cpp
d:\alqualos\pr\testpq>g++ -c -W -Wall a.cpp
d:\alqualos\pr\testpq>g++ -c -W -Wall main.cpp
d:\alqualos\pr\testpq>g++ -o a a.o b.o main.o
d:\alqualos\pr\testpq>a
B::B()
A::A()
B does something!
A::~A()
B::~B()

这是否解决了您的问题，还是我做了完全不同的事情？

编辑1:是否标准？

好的，看来这是对的，但现在它使我们想到了其他有趣的问题。这是我们在下面的评论中讨论的结果。

上例中发生了什么？ a.h文件不需要b.h文件，因为它实际上并没有对b做任何事情，它只是声明了它，并且知道它的大小，因为AutoPtr类中的指针始终是相同的大小。 autoptr.h唯一需要B定义的部分是构造函数和析构函数，但是它们不在a.h中使用，因此a.h不需要包含b.h。

但是为什么a.h不使用B的构造函数呢？每当我们创建A的实例时，B的字段都不会初始化吗？如果是这样，则编译器可能会尝试在A的每个实例中内联此代码，但是它将失败。在上面的示例中，B::B()调用看起来放在a.cpp单元中已编译的构造函数A::A()的开头，但是标准是否要求？

乍一看，似乎没有什么可以阻止编译器在创建瞬间时内联字段初始化代码，因此A a;变成了这个伪代码(当然不是真正的C++):

A a;
a.b->B();
a.A();

这样的编译器可以按照标准存在吗？答案是否定的，他们不能，而且标准与之无关。当编译器编译“main.cpp”单元时，它不知道A::A()构造函数的作用。它可能为b调用了一些特殊的构造函数，因此在将默认的构造函数内联之前，将使用不同的构造函数将b初始化两次!而且，由于定义了A::A()的“a.cpp”单元是单独编译的，因此编译器无法对其进行检查。

好的，现在您可能会想，如果一个智能编译器想要查看B的定义，并且没有除默认构造函数之外的其他构造函数，那么它将不将B::B()调用放入A::A()构造函数中，而是在调用A::A()时内联它。嗯，这不会发生，因为编译器无法保证即使B现在没有任何其他构造函数，将来也不会有任何构造函数。假设我们将其添加到B类定义中的b.h中:

B(int b);

然后，将其定义放在b.cpp中，并相应地修改a.cpp:

A::A():
  b(17) // magic number
{
  printf("A::A()\n");
}

现在，当我们重新编译a.cpp和b.cpp时，即使不重新编译main.cpp，它也将按预期工作。这就是所谓的二进制兼容性，编译器不应该破坏它。但是，如果它内联了B::B()调用，则我们最终得到main.cpp，它调用了两个B构造函数。但是，由于添加构造函数和非虚拟方法永远不会破坏二进制兼容性，因此任何合理的编译器都不应这样做。

此类编译器不存在的最后一个原因是，它实际上没有任何意义。即使成员初始化是内联的，它也只会增加代码的大小，并且绝对不会提高性能，因为仍然有一种方法需要调用A::A()，为什么不让该方法在一个地方完成所有工作呢？

编辑2:好吧，A的内联和自动生成的构造函数呢？

出现的另一个问题是，如果我们同时从a.h和a.cpp中删除A:A()，将会发生什么？这是发生了什么:

d:\alqualos\pr\testpq>g++ -c -W -Wall a.cpp
d:\alqualos\pr\testpq>g++ -c -W -Wall main.cpp
In file included from a.h:4:0,
                 from main.cpp:1:
autoptr.h: In constructor 'AutoPtr<T>::AutoPtr() [with T = B]':
a.h:8:9:   instantiated from here
autoptr.h:8:16: error: invalid use of incomplete type 'struct B'
a.h:6:7: error: forward declaration of 'struct B'
autoptr.h: In destructor 'AutoPtr<T>::~AutoPtr() [with T = B]':
a.h:8:9:   instantiated from here
autoptr.h:9:17: warning: possible problem detected in invocation of delete 
operator:
autoptr.h:9:17: warning: invalid use of incomplete type 'struct B'
a.h:6:7: warning: forward declaration of 'struct B'
autoptr.h:9:17: note: neither the destructor nor the class-specific operator 
delete will be called, even if they are declared when the class is defined.

唯一相关的错误消息是“无效使用不完整类型'struct B'”。基本上，这意味着main.cpp现在需要包含b.h，但是为什么呢？因为当我们在main.cpp中实例化a时会内联自动生成的构造函数。好的，但这是否总是必须发生，还是取决于编译器？答案是它不能依赖编译器。没有编译器可以使自动生成的构造函数成为非内联的。这样做的原因是它不知道将代码放在哪里。从程序员的 Angular 来看，答案是显而易见的:构造函数应该进入定义了类的所有其他方法的单元，但是编译器不知道那是哪个单元。此外，类方法可以分布在多个单元中，有时甚至有意义(例如，类的一部分是由某种工具自动生成的)。

当然，如果我们通过使用inline关键字或将其定义放入A类声明中来使A::A()显式内联，则将发生相同的编译错误，可能会少一些隐含的含义。

结论

对于自动实例化的指针，采用上述技术似乎很好。我唯一不确定的是a.h中的AutoPtr<B> b;是否可以与任何编译器一起使用。我的意思是，在声明指针和引用时我们可以使用正向删除类，但是将其用作模板实例化参数始终正确吗？我认为这没什么问题，但是编译器可能会认为不是。谷歌搜索也没有产生任何有用的结果。