What's your convention for typedef'ing shared_ptr?

Question

I'm flip-flopping between naming conventions for typedef'ing the boost::shared_ptr template. For example:

typedef boost::shared_ptr<Foo> FooPtr;

Before settling on a convention, I'd like to see what others use. What is your convention?

EDIT:

To those nesting the typedef inside Foo, doesn't it bother you that Foo is now "aware" of how it will be passed around? It seems to break encapsulation. How about this:

class Foo
{
public:
    typedef std::vector<Foo> Vector
};

You wouldn't do this now, would you? :-)

Answer 1

I've used the following: typedef boost::shared_ptr<Foo> Foo_rcptr_t;

This clearly indicates that it is a refcounted ptr.

Answer 2

My preference:

class Foo
{
public:

    typedef boost::shared_ptr<Foo> SharedPointer;
};

The problem with just FooPtr is that you may have different types of pointers (e.g., weak_ptrs). I also don't much care for abbreviations, but that's another matter altogether.

Answer 3

It's nice when it ends with _t.

class Bar
{
public:
    typedef boost::shared_ptr<Bar> Ptr_t;
};

Answer 4

I'm not a big fan of Hungarian naming conventions, I usually use:

typedef boost::shared_ptr<Foo> FooSharedPtr;

Detailed enough to be clear but short enough to not be a huge hassle. In any case, I would definitely indicate it's specifically a shared pointer, especially if you're not the only one who's going to be using that type in the future.

Answer 5

I have used both the outer and encapsulated typedef, but ended up with the first,

typedef boost::shared_ptr<Foo> FooPtr; 

solely because in combined expressions this looks cleaner than Foo::Ptr.

doesn't it bother you that Foo is now "aware" of how it will be passed around
Often enough, these classes are creatable through a factory method only:

struct Foo
{
     static FooPtr Create() { return Fooptr(new Foo); }

   protected:
     Foo() {}
}

That's kind of "stronger" than encapsulating the typedef, yet a very common pattern.

Answer 6

This was one of the conventions I was flip-flopping to:

typedef boost::shared_ptr<Foo> FooProxy;

...seeing that boost::shared_ptr is an application of the Proxy pattern.

Answer 7

My first response is to ask, "Why typedef that?"

In reply to your edit: Actually that's a rather interesting approach that could be useful in many situations. Using it to go back to your original question you might have:

struct object
{
  typedef object* ptr_t;
  typedef shared_ptr<object> shared_ptr_t;
  typedef weak_ptr<object> weak_ptr_t;
  typedef unique_ptr<object> unique_ptr_t;
  etc...
}

Answer 8

I usually encapsulate the the typedef inside the class. The reason is that we have some memory sensitive code, and it makes it easy to switch between boost::shared_ptr and boost::intrusive_ptr Since intrusive_ptr is something that the class needs to support, it makes sense to me to have the knowledge of which shared pointer to use be wrapped up in the class.

Answer 9

Answer: don't do it. It's convenient for you and nobody else. Say what you mean.

Answer 10

Personally, in the code I'm responsible for, typically you'd typically see a FooPtr typedef'd at the same namespace scope as Foo and Foo would contain a generically named 'SmartPtr' typedef to the same type as FooPtr. Having FooPtr allows for easy an non-verbose manual usage. having the nested typedef for 'SmartPtr' or some quivalent allows for easy generic usage in templates, macros, etc. without having to know that actual type of the smart pointer.

Also, I'd suggest adding a 'subjective' tag to this question.