为什么不对C ++中的所有内容使用指针？

Question 1

假设我定义了一些类：

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

然后使用它编写一些代码。为什么要执行以下操作？

Pixel p;
p.x = 2;
p.y = 5;

来自Java世界，我总是写：

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

他们基本上做同样的事情，对不对？一个在堆栈上，另一个在堆栈上，因此以后我必须将其删除。两者之间有根本区别吗？为什么我要优先选择另一个？

Question 2

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

首先，显而易见的，次要的是：堆分配很慢。堆栈分配很快。
其次，RAII更重要。由于堆栈分配的版本会自动清除，因此很有用。它的析构函数会自动调用，这使您可以保证清除由该类分配的所有资源。这是避免C ++中内存泄漏的基本方法。通过从不调用delete自己来避免它们，而是将其包装在delete内部通常在其析构函数中调用的堆栈分配对象中。如果您尝试手动跟踪所有分配并delete在正确的时间进行调用，我保证您每100行代码至少会发生一次内存泄漏。

作为一个小示例，请考虑以下代码：

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;
}

很纯真的代码，对不对？我们创建一个像素，然后调用一些不相关的函数，然后删除该像素。有内存泄漏吗？

答案是“可能”。如果bar抛出异常怎么办？delete永远不会被调用，永远不会删除像素，并且我们会泄漏内存。现在考虑一下：

void foo() {
  Pixel p;
  p.x = 2;
  p.y = 5;

  bar();
}

这不会泄漏内存。当然，在这种简单情况下，所有内容都在堆栈上，因此会自动清除它，但是即使Pixel类在内部进行了动态分配，也不会泄漏。该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;
  *p.x = 2;
  *p.y = 5;

  bar();
}

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

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

Question 3

在添加删除之前，它们是不一样的。
您的示例过于琐碎，但析构函数实际上可能包含执行某些实际工作的代码。这称为RAII。

因此，添加删除。即使发生异常，也要确保它发生。

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;
}

如果您选择了一些更有趣的东西，例如文件（该资源需要关闭）。然后使用所需的指针在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.

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

对我来说，主要原因是对象的生存时间。局部定义的对象具有非常特定且定义明确的生存期，并且可以确保在最后调用析构函数（因此可能具有特定的副作用）。另一方面，指针控制具有动态寿命的资源。

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

谁拥有指针的概念。所有者有责任在适当的时候删除对象。这就是为什么您很少在实际程序中看到像这样的原始指针的原因（因为没有所有权信息与原始指针相关联）。相反，指针通常包装在智能指针中。智能指针定义谁拥有内存以及谁负责清理内存的语义。

例如：

 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.

还有其他

Question 4

从逻辑上讲，他们做同样的事情-除了清理。在指针情况下，只是您编写的示例代码会发生内存泄漏，因为该内存没有释放。

来自Java的背景，您可能还不完全了解多少C ++围绕着跟踪已分配的内容以及谁负责释放它。

通过在适当的时候使用堆栈变量，您不必担心释放该变量，它随堆栈框架而消失。

显然，如果您非常谨慎，则始终可以在堆上进行分配并手动进行释放，但是好的软件工程的一部分是，以一种不会破坏的方式构建事物，而不是信任您的超人程序员，福永远不会犯错。