始终存在的动态分配成员的指针或引用？

Question

我有一个类 CContainer，它有一些成员 CMemberX、CMemberY，它们彼此独立且与其他 CClientA 、使用 CContainer 的 CClientB 类。

#include "MemberX.h"
#include "MemberY.h"

class CContainer
{
public:
    CMemberX & GetX() const { return m_x; }
    CMemberY & GetY() const { return m_y; }

private:
    CMemberX m_x;
    CMemberY m_y;
};

我希望避免在使用前向声明以及 m_x 和 动态分配修改 CMember 类之一时重新编译所有 CClient 类m_y。

最初，我制作了成员指针：

// Container.h
class CMemberX;
class CMemberY;

class CContainer
{
public:
    CContainer();
    ~CContainer();

    CMemberX & GetX() const { ASSERT(m_pX != NULL); return *m_pX; }
    CMemberY & GetY() const { ASSERT(m_pY != NULL); return *m_pY; }

private:
    CMemberX* m_pX;
    CMemberY* m_pY;
};

// Container.cpp
#include "Container.h"
#include "MemberX.h"
#include "MemberY.h"

// Allocate members on heap
CContainer::CContainer() : m_pX(new CMemberX()), m_pY(new CMemberY()) {}
CContainer::~CContainer() { delete m_pX; delete m_pY; }

然后我想，我也可以使用引用而不是指针，因此它看起来更像原始代码：

// Container.h
class CMemberX;
class CMemberY;

class CContainer
{
public:
    CContainer();
    ~CContainer();

    CMemberX & GetX() const { return m_x; }
    CMemberY & GetY() const { return m_y; }

private:
    CMemberX & m_x;
    CMemberY & m_y;
};

// Container.cpp
#include "Container.h"
#include "MemberX.h"
#include "MemberY.h"

// Allocate members on heap
CContainer::CContainer() : m_x(*new CMemberX()), m_y(*new CMemberY()) {}
CContainer::~CContainer() { delete &m_x; delete &m_y; }

我不喜欢指针成员的是它看起来< /strong> 就像指针可以为 NULL 或对象在运行时被替换一样，但事实并非如此。

我不喜欢这些参考资料的是 CTor 和 DTor 中的代码看起来有点老套。

哪种方法更可取？有更好的解决方案吗？

有关复制/分配的注意事项：CContainer 类的实例在任何情况下都不会相互复制或分配。

Answer 1

我认为这就是 const 变量的用途：

CMember * const m_x;

初始化后无法更改 m_x...

Answer 2

我认为当存在所有权语义时使用引用有点令人惊讶。考虑到所有因素，这并不一定是一个坏主意，但它确实是不利的。

我想我只在以下情况下使用引用作为成员：

• 向构造函数提供一个对象，这是比该对象寿命更长所必需的。
• 无论如何，赋值都是被禁止的。

例如，注入的依赖项（例如工厂或服务对象）可能是合适的。与此相反，在 C++ 中，您通常更喜欢使用模板参数而不是对象注入依赖项，因此可能不会出现问题。

我还发现，使用 C++ 的时间越长，我就越希望类型可分配，除非有充分的理由不这样做。以您想要的方式减少编译时依赖性的常用技巧是“Pimpl”，而不是“Rimpl”，这是有原因的。通过从对象成员切换到引用成员，您可以使类成为非默认可复制的，而以前它可能是可复制的。此实现细节不应限制类的接口。使用 Pimpl，您可以干净地实现分配和交换。有了这些参考资料，您就必须分配或交换这两个成员。如果第二次交换失败，您就失去了强大的异常保证：尽管如果您的 CMemberX 和 CMemberY 类具有无失败分配和交换，这并不重要。

所以我认为我不喜欢这种情况下的参考，但我还没有看到你的其余代码。也许有一些原因导致没有任何关于赋值的担忧 - 例如，如果 CContainer 本身是一个 RAII 类，那么通常它应该支持的唯一生命周期操作是构造和销毁。

Answer 3

这里有很多关于使用引用作为成员的可取性的问题（例如 我应该更喜欢成员数据中的指针还是引用？），在我看来，大多数人的意见（也恰好是我的）是 - 不。如果您不想更改指针，请将它们设置为常量 - 根据您的代码，我看不出它们如何可能为 NULL。

Answer 4

动态分配对于您想要的东西没有任何帮助：不必重新编译 CClient 和 CContainer。

使用前向声明时唯一允许的用途是声明指向前向声明类型的指针。

一旦您使用前向声明类型的方法或成员，它就不会编译：编译器必须知道它正在使用的任何内容的完整类型。

简而言之：要么你永远不必重新编译[你只是声明指向前向声明类型的指针]，要么你总是必须重新编译，以防你确实使用 CContainer。

Answer 5

Steve Jessop 已经顺便提到了 pImpl 习惯用法，但我认为如果您还没有遇到过它，您应该检查一下：编译防火墙

Answer 6

在问题的第二个代码块中，您有私有成员指针，它们与父类一起初始化和销毁​​。这些信息应该足以让代码的读者了解发生了什么。

此外，您可以将指针声明为 const：CMember* const m_pX; 以指示它们在初始化后无法更改。现在编译器将捕获意外的更改。

Answer 7

你并没有真正给自己买任何东西。
（在有限情况下编译时间稍短）。

但是您正在堆积大量需要维护的其他代码。

如果这些对象是自然成员，则将它们保留为成员。
通过在堆栈上创建它们并将它们存储为指针或引用，您必须提出一大堆需要代码来回答的棘手问题。

• 当您复制构造对象时会发生什么。
  • 我通常希望复制该对象及其所有成员。
    使用指针或引用，您将必须做额外的工作来复制已提供的此功能。
• 当您分配对象时会发生什么。
  • 引用将不起作用（尽管您可以通过使用 boost 引用来解决这个问题）。
    但您仍然存在期望成员被复制的问题。
• 删除对象时会发生什么。
  • 如果您已正确执行上述所有操作，则可以正常复印。
    否则，您需要开始考虑共享指针来实现您需要的功能。

就目前情况而言，版本 2 和 3（问题中的代码）存在严重缺陷，唯一真正有效的版本是 1。

在我看来，一个简单的事实是版本 1 的维护成本会低得多，因此建议使用以下任一版本版本 2 或 3 会适得其反。与添加到代码中的复杂性相比，更改成员时再编译一个类所需的额外时间相对较小。

您还在其他人的评论中提到代码并不像上面描述的那么干净。这只是强调了我的观点，即这是一个糟糕的优化，它将使得类很难正常工作并保持在该状态。