title: Header file best practices for typedefs
body: <p>I'm using shared_ptr and STL extensively in a project, and this is leading to over-long, error-prone types like <code>shared_ptr&lt; vector&lt; shared_ptr&lt;const Foo&gt; &gt; &gt;</code> (I'm an ObjC programmer by preference, where long names are the norm, and still this is way too much.) It would be much clearer, I believe, to consistently call this <code>FooListPtr</code> and documenting the naming convention that "Ptr" means shared_ptr and "List" means vector of shared_ptr.</p>
  
  <p>This is easy to typedef, but it's causing headaches with the headers. I seem to have several options of where to define <code>FooListPtr</code>:</p>
  
  <ul>
  <li>Foo.h. That entwines all the headers and creates serious build problems, so it's a non-starter.</li>
  <li>FooFwd.h ("forward header"). This is what <em>Effective C++</em> suggests, based on iosfwd.h. It's very consistent, but the overhead of maintaining twice the number of headers seems annoying at best.</li>
  <li>Common.h (put all of them together into one file). This kills reusability by entwining a lot of unrelated types. You now can't just pick up one object and move it to another project. That's a non-starter.</li>
  <li>Some kind of fancy #define magic that typedef's if it hasn't already been typedefed. I have an abiding dislike for the preprocessor because I think it makes it hard for new people to grok the code, but maybe....</li>
  <li>Use a vector subclass rather than a typedef. This seems dangerous...</li>
  </ul>
  
  <p>Are there best practices here? How do they turn out in real code, when reusability, readability and consistency are paramount?</p>
  
  <p>I've marked this community wiki if others want to add additional options for discussion.</p>