如何在 C++ 中管理成员变量

Question

简而言之，我的问题是关于成员变量作为非托管 C++ 中的指针。

在 java 或 c# 中，我们有“高级指针”。事实上，我们无法察觉其中的“指针”。我们通常这样初始化一个类的成员：

member = new Member();

或

member = null;

但在 c++ 中，它变得更加混乱。我见过很多样式：使用new，或者将成员变量留在堆栈中。

在我看来，使用boost::shared_ptr 似乎很友好，但在 boost 本身的源代码中到处都有news。这是效率的问题，不是吗？

有没有“尽量避免new”之类的准则？

编辑

我意识到说“将它们留在堆栈中”是不恰当的，这是一种更恰当的说法：当我需要一个 object 作为我的成员变量时，我应该更喜欢 object 而不是 object* ?

Answer 1

Boost 源代码不是您应该如何编写源代码的好例子。 Boost 库旨在封装所有繁琐、困难和容易出错的代码，这样您就不必担心代码中的这些问题。

最好的办法是在代码中遵循两条一般规则：

• 不要在不需要使用指针的地方使用指针
• 在确实需要使用指针的地方，使用智能指针（如 shared_ptr 或 scoped_ptr）

Answer 2

是的，有一个准则 - 仅在必须时使用动态分配。很多时候你可以而且应该使用值，而不是指针。例如，您应该几乎总是使用：

vector <string> v;

而不是：

vector <string *> v;

并动态分配字符串。

Answer 3

当然，如果您在构造函数中执行一次 new 并在析构函数中执行一次 delete，它当然不会杀死您。在这种简单的情况下，使用智能指针只是毫无意义的开销。

如果您变得更复杂，或者如果您对异常安全感到偏执，那么智能指针可能是个好主意。

Answer 4

Stroustrup 的guide to the language：

Scott Meyers 的三元组非常有用：Effective C++,More Effective C++，和 Effective STL.

另请参阅以下问题：
- https://stackoverflow.com/questions/155762/best-c-resource
- Java FAQ equivalent of C++ FAQ lite?
- C++ : handle resources if constructors may throw exceptions (Reference to FAQ 17.4]
- What C++ pitfalls should I avoid?
- New to C++. Question about constant pointers

Answer 5

使用shared_ptr 的好处是它是一个“智能指针”，不需要显式的delete 来释放内存。否则，如果您使用new，则一旦不再需要该对象，您将不得不显式调用delete 来释放分配的内存。

Answer 6

在 C++ 中，这是开发人员的选择问题。有更多的权力，但也有更多的责任。

例子：

声明具有任意大小内部存储的对象的类。

1. 如果您将此类设计为在实例化时分配最坏情况的存储，则可以完全避免使用指针。但就平均情况而言，内存使用成本很高。

2. 如果您将类设计为根据其需要分配内存，您可能会选择使用指针。然后每个实例将只从堆中获取它需要的东西。但是你必须小心避免指针错误。

3. 如果您将类设计为根据其需要分配内存，您可能仍然能够避免使用内存抽象的指针（即 auto_ptr 或自定义缓冲区方案等）。

   李>

因此，一个指导方针可能是在应用程序代码中使用裸指针之前探索可用的选项。库代码的平衡可能会有所不同，因为它的范围更有限，可能对性能更敏感，并且（希望）经过更好的测试。

Answer 7

您可能希望使用 C++ STL 类“autoptr”来管理您的内存。

另外，在 C++ 中，如果是成员变量，则不一定是指针。

class MyClass
{
    MyClass();

    MyMember a;
    MyMember* b;
    std::auto_ptr<MyMember> c;
}

MyClass::MyClass()
{
    // constructer
    // a is now instantiated -- I don't have to do anything
    b = new MyMember(); // I'll have to delete it in the destructor
    c.reset(new MyMember()); // I won't have to delete it in the destructor
}