核心原因是堆上的对象总是比简单值更难使用和管理。编写易于阅读和维护的代码始终是任何认真的程序员的首要任务。

另一种情况是，我们使用的库提供了值语义，使动态分配变得不必要。Std::string就是一个很好的例子。

然而，对于面向对象的代码，使用指针——这意味着使用new来预先创建指针——是必须的。为了简化资源管理的复杂性，我们有几十种工具使其尽可能简单，比如智能指针。基于对象的范式或泛型范式假设值语义，并需要更少或不需要新的，正如其他地方的海报所述。

传统的设计模式，尤其是GoF书中提到的那些，大量使用new，因为它们是典型的面向对象代码。

New在堆上分配对象。否则，对象分配在堆栈上。查一下两者的区别。

避免过度使用堆的一个值得注意的原因是为了性能——特别是涉及c++使用的默认内存管理机制的性能。虽然在简单的情况下分配可以非常快，但是在没有严格顺序的情况下对大小不一致的对象执行大量的新建和删除操作不仅会导致内存碎片，而且还会使分配算法复杂化，并且在某些情况下绝对会破坏性能。

这就是创建内存池要解决的问题，可以减轻传统堆实现的固有缺点，同时仍然允许您在必要时使用堆。

不过，最好还是完全避免这个问题。如果可以将它放到堆栈中，那么就这样做。

我想海报的意思是，你不必把所有的东西都分配到堆上，而不是堆栈上。

基本上，对象是在堆栈上分配的(当然，如果对象大小允许的话)，因为堆栈分配的成本较低，而不是基于堆的分配，后者涉及分配器的大量工作，并增加了冗长的内容，因为这样您就必须管理分配在堆上的数据。

两个原因:

在这种情况下没有必要。您正在使代码不必要地变得更加复杂。 它在堆上分配空间，这意味着您必须记住稍后删除它，否则将导致内存泄漏。

Pre-C + + 17:

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

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

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

这段代码很危险，因为不能保证在T1或T2之前构造shared_ptr。因此，如果新T1()或新T2()中的一个在另一个成功后失败，那么第一个对象将被泄露，因为不存在shared_ptr来销毁和释放它。

解决方法:使用make_shared。

Post-C + + 17:

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

Barry在另一个回答中提供了关于c++ 17引入的新求值顺序的更详细的解释。

感谢@Remy Lebeau指出这在c++ 17中仍然是一个问题(尽管不是那么严重):shared_ptr构造函数可能无法分配它的控制块和抛出，在这种情况下，传递给它的指针不会被删除。

解决方法:使用make_shared。