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.
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.
