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.

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.

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.

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.

Yes.