Should C++ fields be pointers or objects?

Question

I'm wondering whether it is better to make object fields within a class objects or pointers. Specifically it seems that using an object field requires the entire header for that object's class to be included, where as with an object pointer you can get by with a simpler forward class declaration.

For example, which is better, an object field:

Classifier.h

#include "normalizer.h"

class Classifier {
 public:
  Classifier(const Normalizer& normalizer);
 private:
  const Normalizer normalizer_;
};

Classifier.cpp

#include "classifier.h"
#include "normalizer.h"

Classifier::Classifier(const Normalizer& normalizer)
    : normalizer_(normalizer) {}

Or an object pointer field:

Classifier.h

class Normalizer;

class Classifier {
 public:
  Classifier(const Normalizer& normalizer);
 private:
  const Normalizer* normalizer_;
};

Classifier.cpp

#include "normalizer.h"

Classifier::Classifier(const Normalizer& normalizer)
    : normalizer_(new Normalizer(normalizer)) {}

Classifier::~Classifier() {
  delete normalizer_;
}

Answer 1

They should definately by objects in nearly all situations (there are exceptions).

What you have described above is the PIMPL pattern (also see pimpl vs brige).
This allows you to abstract and hide implementation details from the user of your class (a sometimes useful technique).

Note: There is a problem with your second example is that you have not specified ownership semantics (and thus not correctly implemented the rule of three (which can be fixed by using smart pointers rather than RAW pointers)).

The claim of the advantage that "forward declaration is simpler" is not true. What you are doing is shifting responsibility. If you use objects in your class then you need to included the header files. If you use pointers then you only need forward declarations. But at some point when the object is used you need to include its header file. So all you have done is shift the point at where the header file needs to be included. If you put it in your header file the user does not need to know (and thus is not tightly coupled) about any dependencies inside your objects (they just include your header).

Answer 2

I will attempt to answer the member-vs-pointer question generally.

These are the consequences of making the inner object itself a member of the outer object:

• The entire object's data will be contained within the outer object. This may have memory usage implications, if the inner object is a large one.
• The inner object must exist for the entire lifetime of the outer object; no more and no less. And there must be a 1-to-1 mapping of inner to outer objects.
• Because there is no pointer indirection, access to the inner is faster (but not always!).
• There are no special memory management concerns - the compiler takes care of allocation, construction and destruction in the outer object's constructer and destructor.
• The header for the outer class needs to include the header for the inner class.

And of course if the member is a pointer, the reverse of all of the above applies.

One of the key concerns with using pointers is making sure memory is properly managed. In C++ this can be almost entirely mitigated with proper use of smart_ptr (or auto_ptr if you can't get smart_ptr for some reason).

Don't try too hard to make things easier for the compiler. If you want your inner object to be a member, then let the compiler read that header file. It's a tool, make it work.