title: What's the best strategy for typedef'ing shared pointers?
body: <p>I have a quick question regarding the use of typedefs for lengthy templates. The crux: I've found myself in something of a pickle—there doesn't seem to be a good place to place typedefs except local to client functions. While there are similar <em>SO</em> questions (see <a href="https://stackoverflow.com/questions/2717436/whats-your-convention-for-typedefing-shared-ptr">here</a> for example), none seem to address this exactly. Please note that this question doesn't address whether typedefs are desirable in what follows—I've tried to simplify things for expository purposes.</p>
  
  <p>My problem has arisen while working with <code>boost::shared_ptr&lt;T&gt;</code>.  Basically, I want to do the following:</p>
  
  <pre><code>#include &lt;boost/shared_ptr.hpp&gt;
  typedef boost::shared_ptr&lt;Widget&gt; WidgetPtr;
  </code></pre>
  
  <p>Placing this typedef in the <code>Widget</code> declaration header seems ugly. There seem to be two considerations here: (i) if <code>Widget</code> itself doesn't make use of shared pointers in its members, we've added an additional include (as we can't forward declare the <code>boost::shared_ptr</code> template class—correct me if I'm wrong?) (ii) if we want to make use of this typedef during the declaration of another class (call that class <code>Foo</code>) we violate best practices by including <code>Widget.h</code> instead of simply forward declaring <code>Widget</code> or including <code>WidgetFwd.h</code>... unless this typedef is duplicated in the latter. Furthermore, it doesn't seem make sense to typedef <code>boost::shared_ptr&lt;Widget&gt;</code> during the declaration of <code>Widget</code> itself—we seem to be mixing <code>Widget</code>'s declaration with an anticipation of how clients will make use of the <code>Widget</code> interface.</p>
  
  <p>Okay, so that's bad, but this is worse: if I don't attempt some combination of the above I end up with duplicate typedefs in client code, which yields inconsistency (and hence, likely, error)—the whole point being that given <code>Widget</code>, a <code>WidgetPtr</code> typedef should act as a type in its own right. Example: we don't want <code>Foo</code> to make use of one <code>WidgetPtr</code>, a typedef of <code>boost::shared_ptr</code>, while <code>Bar</code> is using WidgetPtr as a typedef for <code>std::auto_ptr</code>.</p>
  
  <p>Another method (and one of the few that I've seen mentioned in online discussion) would be to make the typedef a public member of <code>Widget</code> and then use <code>Widget::Ptr</code>:</p>
  
  <pre><code>class Widget {
  // ...
  public:
       typedef boost::shared_ptr&lt;Widget&gt; Ptr;
  };
  </code></pre>
  
  <p>Again, I don't like this as (i) it suggests that the pointer type is somehow a member of the class and (ii) it leads to a wonky interface. Worse still: since every class that I write can potentially be pointed to using smart pointers, I end up chasing the imaginary client's tail. Ugly, ugly, ugly.</p>
  
  <p>As it stands, I've removed the typedefs from this codebase (as they led to serious confusion, duplication) and re-introduced them locally in selected functions. Here again there's a problem with inconsistent usage but it's not quite as severe.</p>
  
  <p>The only other solution I can think of—and again I'm not sure whether this is considered good practice—would be to have a utilities header in which the typedefs are placed, potentially within their own namespace. In this header we'd include  and be done with it.</p>
  
  <p>Am I missing something obvious or is this just plain tricky?</p>
  
  <p>PS—Apologies for the length of the above; I couldn't find a simpler way of fully expressing the problem.</p>