I\'m flip-flopping between naming conventions for typedef\'ing the boost::shared_ptr template. For example:
typedef boost::shared_ptr FooPtr;
How about:
template <typename T>
class Shared
{
public:
typedef std::shared_ptr<T> Ptr; // or boost::shared_ptr if you will
};
Then allowing any Shared
class to have their own Ptr object, as in:
class myClass : public Shared<myClass>
{
};
int main()
{
myClass::Ptr object;
//...
object->foo();
}
It's nice when it ends with _t
.
class Bar
{
public:
typedef boost::shared_ptr<Bar> Ptr_t;
};
Personally, in the code I'm responsible for, 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.
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.
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.
typedef shared_ptr<Foo> sptr_Foo;
typedef weak_ptr<Foo> wptr_Foo;
typedef unique_ptr<Foo> uptr_Foo;