为什么不在C ++中使用指针？

假设我定义了一些类：

class Pixel { public: Pixel(){ x=0; y=0;}; int x; int y; }

然后使用它编写一些代码。我为什么要做下面的事情？

 Pixel p; px = 2; py = 5;

来自Java世界，我总是写：

 Pixel* p = new Pixel(); p->x = 2; p->y = 5;

他们基本上做同样的事情，对吧？一个在栈上，另一个在堆上，所以我将不得不删除它。两者有什么根本的区别？为什么我应该比另一个更喜欢？

是的，一个在栈上，另一个在堆上。有两个重要的区别：

首先，显而易见的并不重要的一点是堆分配缓慢。堆栈分配很快。
其次，更重要的是RAII 。因为堆栈分配的版本会自动清理，所以它很有用 。它的析构函数会自动调用，这样可以保证清除类中分配的任何资源。这是你如何避免C ++中的内存泄漏的根本原因。你可以通过不要自己调用delete来避免它们，而是把它封装在堆栈分配的对象中，这些对象在内部调用delete ，在析构函数中是典型的。如果您尝试手动跟踪所有分配，并在正确的时间调用delete ，那么我保证每100行代码至less会有一次内存泄漏。

作为一个小例子，考虑这个代码：

 class Pixel { public: Pixel(){ x=0; y=0;}; int x; int y; }; void foo() { Pixel* p = new Pixel(); p->x = 2; p->y = 5; bar(); delete p; }

漂亮的代码，对吧？我们创build一个像素，然后我们调用一些不相关的函数，然后删除像素。有没有内存泄漏？

答案是“可能”。如果bar抛出一个exception会发生什么？ delete永远不会被调用，像素永远不会被删除，我们会泄漏内存。现在考虑一下：

 void foo() { Pixel p; px = 2; py = 5; bar(); }

这不会泄漏内存。当然，在这种简单的情况下，所有东西都在堆栈中，所以它会自动清理，但即使Pixel类在内部进行了dynamic分配，也不会泄漏。 Pixel类将被简单地赋予一个析构函数来删除它，并且无论我们如何离开foo函数，都会调用这个析构函数。即使我们离开它，因为bar抛出一个例外。以下稍微做作的例子显示了这一点：

 class Pixel { public: Pixel(){ x=new int(0); y=new int(0);}; int* x; int* y; ~Pixel() { delete x; delete y; } }; void foo() { Pixel p; *px = 2; *py = 5; bar(); }

Pixel类现在在内部分配一些堆内存，但是它的析构函数负责清理它，所以在使用类时，我们不必担心。（我应该提一下，这里最后一个例子被简化了很多，为了显示一般的原则，如果我们真的要使用这个类，它也包含了几个可能的错误，如果y的分配失败，x永远不会被释放，如果像素被复制，我们最终会试图删除相同的数据，所以最后一个例子就是用一些盐来代替，现实世界的代码有点复杂，但是它显示了一般的想法）

当然，相同的技术可以扩展到除内存分配之外的其他资源。例如，它可以用来保证在使用后closures文件或数据库连接，或者释放线程代码的同步锁。

直到你添加删除它们是不一样的。
你的例子是微不足道的，但是析构函数实际上可能包含一些真正的工作的代码。这被称为RAII。

所以添加删除。确保即使exception正在传播时也会发生。

 Pixel* p = NULL; // Must do this. Otherwise new may throw and then // you would be attempting to delete an invalid pointer. try { p = new Pixel(); p->x = 2; p->y = 5; // Do Work delete p; } catch(...) { delete p; throw; }

如果你select了一个更有趣的文件（这是一个需要closures的资源）。然后在Java中用正确的指针来做到这一点。

 File file; try { file = new File("Plop"); // Do work with file. } finally { try { file.close(); // Make sure the file handle is closed. // Oherwise the resource will be leaked until // eventual Garbage collection. } catch(Exception e) {};// Need the extra try catch to catch and discard // Irrelevant exceptions. // Note it is bad practice to allow exceptions to escape a finally block. // If they do and there is already an exception propagating you loose the // the original exception, which probably has more relevant information // about the problem. }

在C ++中相同的代码

 std::fstream file("Plop"); // Do work with file. // Destructor automatically closes file and discards irrelevant exceptions.

虽然人们提到速度（因为在堆上查找/分配内存）。就个人而言，这不是一个决定性的因素（分配器非常快速，并已针对不断创build/销毁的小对象的C ++使用进行了优化）。

我的主要原因是对象的生命时间。一个本地定义的对象有一个非常具体和定义良好的生命周期，并保证析构函数在最后被调用（因此可以有特定的副作用）。另一方面，指针控制具有dynamic寿命的资源。

C ++和Java的主要区别是：

谁拥有指针的概念。所有者有责任在适当的时候删除该对象。这就是为什么在真正的程序中很less看到这样的原始指针（因为没有与原始指针相关的所有权信息）。而指针通常包含在智能指针中。智能指针定义谁拥有内存的语义，从而谁负责清理它。

例子是：

  std::auto_ptr<Pixel> p(new Pixel); // An auto_ptr has move semantics. // When you pass an auto_ptr to a method you are saying here take this. You own it. // Delete it when you are finished. If the receiver takes ownership it usually saves // it in another auto_ptr and the destructor does the actual dirty work of the delete. // If the receiver does not take ownership it is usually deleted. std::tr1::shared_ptr<Pixel> p(new Pixel); // aka boost::shared_ptr // A shared ptr has shared ownership. // This means it can have multiple owners each using the object simultaneously. // As each owner finished with it the shared_ptr decrements the ref count and // when it reaches zero the objects is destroyed. boost::scoped_ptr<Pixel> p(new Pixel); // Makes it act like a normal stack variable. // Ownership is not transferable.

还有其他的。

从逻辑上讲，他们做同样的事情 – 除了清理。只是你写的示例代码在指针的情况下有一个内存泄漏，因为这个内存没有被释放。

从Java的背景来看，你可能没有完全准备好C ++究竟有多less是围绕着分配什么东西以及谁来负责释放它。

通过适当的使用堆栈variables，您不必担心释放该variables，堆栈框架就会消失。

显然，如果你非常小心，你总是可以在堆上分配，而且可以手动释放，但是好的软件工程的一部分就是要build立一些不会破坏的东西，而不是相信你的超人类程序员 – 福永不犯错。