StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POWhat's the best strategy for typedef'ing shared pointers?
text
Body
copied!<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<T></code>. Basically, I want to do the following:</p> <pre><code>#include <boost/shared_ptr.hpp> typedef boost::shared_ptr<Widget> 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<Widget></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<Widget> 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>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload