Hacker News Reader

Comment by fusiongyro | Hacker News Reader

Can you expand on using C++ without "new" or "delete"? I'm curious. I'm learning C++11 now and I'm having trouble seeing how you could do that.

View on HN

In addition to what is talked about below, using value semantics (with mutable or immutable objects) can be helpful. Lots of types can be given value semantics and end up more efficient (most people think copying == less efficient, always) due to the lack of pointers and the locality destroying/cache unfriendliness they introduce. In my experience if you see new/delete in C++ code you should be immediately questioning who owns that object, how it is shared and how/when it is destroyed. I can't even count the number of times I have seen one object new up something and then share a raw pointer with N other objects, who then either have to coordinate who calls delete or, the creator itself does so, and you may have use-after-free issues. unique_ptr and shared_ptr, or their moral equivalents, help avoid most of these issues. As a bonus shared_ptr enables weak_ptr, which can also be very handy for non-owning users and breaking cycles in object graphs.

If you use smart pointers in your code (std::unique_ptr, std::shared_ptr), you will rarely have to call delete. A unique_ptr for example owns an object through a pointer; the pointer is automatically deleted when the unique_ptr goes out of scope. shared_ptr retains shared ownership through reference counting; the pointer is deleted when the reference count reaches zero.

So, in your code you would never write this:

    class Foo {
      ...
    private:
      Bar *myBar;
      Baz *myBaz;
    };

You would instead always do something like this:

    class Foo {
      ...
    private:
      shared_ptr<Bar> myBar;
      unique_ptr<Baz> myBaz;
    };

Is that right?

Yes.

Using your example let's assume myBar and myBaz are _owned_ by Foo. Before C++11 you would typically do this:

   class Foo {
   public:
      Foo() : myBar(0), myBaz(0)
      {
         myBar = new Bar;
         myBaz = new Baz;
      }
      ~Foo
      {
         if (myBar) delete myBar;
         if (myBaz) delete myBaz;
      }
   private:
      Bar *myBar;
      Baz *myBaz;
   };

In C++11, the above could be written like this:

   class Foo {
   public:
      Foo() : myBar(new Bar), myBaz(new Baz)
      {
      }
   private:
      std::unique_ptr<Bar> myBar;
      std::unique_ptr<Baz> myBaz;
   };

You don't need to call delete because the unique_ptr destructor will do it for you.

You would only need to use shared_ptr when ownership is shared among multiple objects. A shared_ptr holds a reference counter that is incremented every time it is copied, and decremented every time it is destroyed or re-assigned. When the reference counter reaches zero, the pointer is automatically deleted.

And once they get around to adding std::make_unique (or you add it to your codebase yourself), you won't even need new there either.

Pre C++11 you would use a scoped_ptr in that scenario. And for the record, the conditionals in that destructor are redundant, deleting a null pointer does nothing.

You can also use:

    Bar myBar;
    Baz myBaz;

Depends on the situation. I'm asking about pointers specifically because I have a situation in which the lifetime of the property is different than the lifetime of my object.

It always depends on the situation. :)

C++ encourages hiding the data inside an object, in which case the lifetime of the data will be the same.

Sometimes the wrapped data has to be exposed directly, e.g. graphics pipeline needs direct access for performance reason. Even in that case it is useful to have a class. For example the VTK image reader class will handle a lot of bit depth related differences transparently. Makes it possible to store different image types with different bit depth in a single container and most of the access is still trough interface (e.g. GetWidth).

My first decent sized program is to parse a strange file format that contains multiple tables into a DOM-like representation, and then output that DOM to CSV.

What I have so far, is a SAX-like event-driven parser that works, and I have a CSV writer that works, and I have hooked them together, and that works. I managed to avoid using pointers for that chunk of code.

For the DOM building portion, I need to allocate table and row objects while I'm getting events, and since I don't know ahead of time how many of each I'm going to have, I more-or-less must have a pointer to "the current" table, and then when that table is complete or I run out of document I can add it to the document object. So the lifespans are not identical anymore: the builder is going to have to allocate tables as it builds and probably rows as well.

At the moment I'm using pointers, and I just make a new table or row when appropriate and then add it back to the container. But this is a little messy because the containers are, you know, vector<table> and vector<row> and they don't need to think in terms of pointers for that reason. So I wind up passing currentTable and currentRow to the add methods, which probably makes copies on the stack.

I am sure that somebody with more C++ experience would see the right way to do this. My experience is largely with conventional OO languages (i.e. memory managed) and functional programming languages. So I'm a little lost on how to structure this.

Reply on news.ycombinator.com