为什么 C++ 程序员应该尽量减少“新”的使用？

有两种广泛使用的内存分配技术：自动分配和动态分配。通常，每个都有一个相应的内存区域：堆栈和堆。

堆

堆栈总是按顺序分配内存。它可以这样做是因为它要求您以相反的顺序（先进后出：FILO）释放内存。这是许多编程语言中局部变量的内存分配技术。它非常非常快，因为它需要最少的簿记并且要分配的下一个地址是隐式的。

在 C++ 中，这称为 自动存储，因为存储在作用域结束时会自动声明。当前代码块（使用 {} 分隔）的执行完成后，将自动收集该块中所有变量的内存。这也是调用 析构函数 来清理资源的时刻。

堆

堆允许更灵活的内存分配模式。簿记更复杂，分配更慢。由于没有隐式释放点，您必须使用 delete 或 delete[]（C 中的 free）手动释放内存。然而，没有隐式释放点是堆灵活性的关键。

使用动态分配的原因

即使使用堆的速度较慢并且可能导致内存泄漏或内存碎片，动态分配也有非常好的用例，因为它的限制较少。

使用动态分配的两个主要原因：

您不知道编译时需要多少内存。例如，在将文本文件读入字符串时，您通常不知道文件的大小，因此在运行程序之前您无法决定分配多少内存。

您想要分配在离开当前块后将持续存在的内存。例如，您可能想要编写一个函数 string readfile(string path) 来返回文件的内容。在这种情况下，即使堆栈可以保存整个文件内容，您也无法从函数返回并保留分配的内存块。

为什么动态分配通常是不必要的

在 C++ 中有一个简洁的构造，称为 析构函数。此机制允许您通过将资源的生命周期与变量的生命周期对齐来管理资源。这种技术被称为 RAII 并且是 C++ 的区别点。它将资源“包装”到对象中。 std::string 就是一个很好的例子。这个片段：

int main ( int argc, char* argv[] )
{
    std::string program(argv[0]);
}

实际上分配了可变数量的内存。 std::string 对象使用堆分配内存并在其析构函数中释放它。在这种情况下，您确实不需要需要手动管理任何资源，并且仍然可以获得动态内存分配的好处。

特别是，这意味着在此代码段中：

int main ( int argc, char* argv[] )
{
    std::string * program = new std::string(argv[0]);  // Bad!
    delete program;
}

有不需要的动态内存分配。该程序需要更多的输入（！）并引入了忘记释放内存的风险。它这样做没有明显的好处。

为什么应该尽可能频繁地使用自动存储

基本上，最后一段总结了它。尽可能频繁地使用自动存储使您的程序：

打字速度更快；

运行时更快；

不太容易发生内存/资源泄漏。

奖励积分

在引用的问题中，还有其他问题。特别是以下类：

class Line {
public:
    Line();
    ~Line();
    std::string* mString;
};

Line::Line() {
    mString = new std::string("foo_bar");
}

Line::~Line() {
    delete mString;
}

实际上使用起来比下面的风险大得多：

class Line {
public:
    Line();
    std::string mString;
};

Line::Line() {
    mString = "foo_bar";
    // note: there is a cleaner way to write this.
}

原因是 std::string 正确定义了复制构造函数。考虑以下程序：

int main ()
{
    Line l1;
    Line l2 = l1;
}

使用原始版本，该程序可能会崩溃，因为它在同一字符串上使用了两次 delete。使用修改后的版本，每个 Line 实例都将拥有自己的字符串 instance，每个实例都有自己的内存，并且都将在程序结束时释放。

其他注意事项

由于上述所有原因，广泛使用 RAII 被认为是 C++ 中的最佳实践。但是，还有一个不是立即显而易见的额外好处。基本上，它比各个部分的总和要好。整个机制组成。它可以扩展。

如果您使用 Line 类作为构建块：

 class Table
 {
      Line borders[4];
 };

然后

 int main ()
 {
     Table table;
 }

分配四个 std::string 实例、四个 Line 实例、一个 Table 实例和所有字符串的内容，自动释放所有内容。

---

因为堆栈更快且防泄漏

在 C++ 中，只需要一条指令即可为给定函数中的每个局部范围对象分配空间（在堆栈上），并且不可能泄漏任何内存。该评论打算（或应该打算）说“使用堆栈而不是堆”之类的东西。

---

原因很复杂。

首先，C++ 不是垃圾收集器。因此，对于每一个新的，都必须有一个相应的删除。如果你没有把这个删除，那么你有内存泄漏。现在，对于这样一个简单的案例：

std::string *someString = new std::string(...);
//Do stuff
delete someString;

这很简单。但是如果“Do stuff”抛出异常会发生什么？糟糕：内存泄漏。如果“Do stuff”提前发出 return 会发生什么？糟糕：内存泄漏。

这是最简单的情况。如果您碰巧将该字符串返回给某人，现在他们必须删除它。如果他们将它作为参数传递，接收它的人是否需要删除它？他们什么时候应该删除它？

或者，您可以这样做：

std::string someString(...);
//Do stuff

没有delete。该对象是在“堆栈”上创建的，一旦超出范围就会被销毁。您甚至可以返回对象，从而将其内容传输到调用函数。您可以将对象传递给函数（通常作为引用或 const-reference: void SomeFunc(std::string &iCanModifyThis, const std::string &iCantModifyThis)。等等。

全部没有 new 和 delete。毫无疑问，谁拥有内存或谁负责删除它。如果你这样做：

std::string someString(...);
std::string otherString;
otherString = someString;

据了解，otherString 拥有 someString 的数据的副本。它不是指针；它是一个单独的对象。它们可能恰好具有相同的内容，但您可以更改其中一个而不影响另一个：

someString += "More text.";
if(otherString == someString) { /*Will never get here */ }

看到这个想法了吗？

---

new 创建的对象必须最终delete d，以免它们泄漏。析构函数不会被调用，内存不会被释放，整个位。由于 C++ 没有垃圾收集，所以这是一个问题。

按值创建的对象（即在堆栈上）在超出范围时会自动死亡。析构函数调用由编译器插入，内存在函数返回时自动释放。

像 unique_ptr、shared_ptr 这样的智能指针解决了悬空引用问题，但它们需要编码纪律并且存在其他潜在问题（可复制性、引用循环等）。

此外，在多线程场景中，new 是线程之间的争用点；过度使用 new 可能会影响性能。根据定义，堆栈对象的创建是线程本地的，因为每个线程都有自己的堆栈。

值对象的缺点是一旦宿主函数返回它们就会死掉——你不能将引用传回给调用者，只能通过复制、返回或按值移动。

---

C++ 本身不使用任何内存管理器。其他语言如 C#、Java 有垃圾收集器来处理内存

C++ 实现通常使用操作系统例程来分配内存，过多的新/删除可能会使可用内存碎片化

对于任何应用程序，如果经常使用内存，建议预先分配它并在不需要时释放它。

不正确的内存管理可能会导致内存泄漏，而且很难跟踪。所以在函数范围内使用栈对象是一种行之有效的技术

使用堆栈对象的缺点是，它会在返回、传递给函数等时创建多个对象副本。然而，智能编译器很清楚这些情况，并且已经针对性能进行了很好的优化

如果在两个不同的地方分配和释放内存，在 C++ 中真的很乏味。释放的责任始终是一个问题，我们主要依赖于一些常用的可访问指针、堆栈对象（最大可能）和 auto_ptr（RAII 对象）等技术

最好的事情是，您可以控制内存，最糟糕的是，如果我们对应用程序使用不正确的内存管理，您将无法控制内存。由于内存损坏导致的崩溃是最严重且难以追踪的。

---

我发现遗漏了一些尽可能少做新事物的重要原因：

运算符 new 具有不确定的执行时间

调用 new 可能会也可能不会导致操作系统为您的进程分配一个新的物理页面，如果您经常这样做，这可能会非常慢。或者它可能已经准备好合适的内存位置，我们不知道。如果您的程序需要具有一致且可预测的执行时间（例如在实时系统或游戏/物理模拟中），您需要在时间关键循环中避免 new。

运算符 new 是隐式线程同步

是的，你听到了，你的操作系统需要确保你的页表是一致的，因此调用 new 会导致你的线程获取一个隐式互斥锁。如果您一直在从许多线程调用 new，那么您实际上是在序列化您的线程（我已经使用 32 个 CPU 完成了此操作，每个 CPU 都在 new 上获得几百个字节，哎呀！这是一个要调试的皇家皮塔)

其他答案已经提到了其他答案，例如速度慢、碎片化、容易出错等。

---

C++17 之前：

因为即使您将结果包装在智能指针中，它也容易发生微妙的泄漏。

考虑一个“细心”的用户，他记得将对象包装在智能指针中：

foo(shared_ptr<T1>(new T1()), shared_ptr<T2>(new T2()));

此代码很危险，因为无法保证 shared_ptr 是在 T1 或 T2 之前构造的。因此，如果 new T1() 或 new T2() 之一在另一个成功后失败，则第一个对象将被泄漏，因为不存在 shared_ptr 来销毁和释放它。

解决方案：使用make_shared。

后 C++17：

这不再是一个问题：C++17 对这些操作的顺序施加了约束，在这种情况下，确保每次调用 new() 之后必须立即构造相应的智能指针，没有之间的其他操作。这意味着，在调用第二个 new() 时，可以保证第一个对象已经被包装在其智能指针中，从而防止在引发异常时发生任何泄漏。

Barry in another answer 提供了对 C++17 引入的新评估顺序的更详细说明。

感谢 @Remy Lebeau 指出这仍然在 C++17 下是一个问题（尽管不太严重）：shared_ptr 构造函数可能无法分配其控制块并抛出，在这种情况下传递给它的指针不会被删除。

解决方案：使用make_shared。

---

其他解决方案：永远不要为每行动态分配一个以上的对象。

@Antimony：是的，与没有分配任何对象相比，当您已经分配了一个对象时，分配多个对象更具诱惑力。

我认为更好的答案是，如果调用异常并且没有任何东西捕获它， smart_ptr 会泄漏。

即使在 C++17 后的情况下，如果 new 成功并且随后的 shared_ptr 构造失败，仍然可能发生泄漏。 std::make_shared() 也可以解决这个问题

@Mehrdad 有问题的 shared_ptr 构造函数为存储共享指针和删除器的控制块分配内存，所以是的，理论上它可以引发内存错误。只有复制、移动和别名构造函数是不抛出的。 make_shared 在控制块本身内部分配共享对象，因此只有 1 个分配而不是 2 个。