What is your convention for typedef'ing shared_ptr?

Question

I am moving between naming conventions for the typedef'ing of the boost :: shared_ptr template. For example:

typedef boost::shared_ptr<Foo> FooPtr; 

Before embarking on an agreement, I would like to see what others are using. What is your convention?

EDIT:

For those nested inside a typedef inside Foo, doesn't it bother you that Foo is now “aware” of how it will be passed? It seems to destroy encapsulation. How about this:

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

You wouldn’t do it now, would you ?:-)

Answer 1

I would also add some variations of this old question, although they can be very controversial ...

Like OldPeculier's answer, I like short type names that resemble standard pointers as closely as possible.

In a project that used shared_pointer almost everywhere, I used

 typedef boost::shared_ptr<Foo> Foo_; // usage examples: Foo* myFoo0; Foo_ myFoo1; 

I took advantage of three things:

• The underscore somehow looks like an operator, but is basically treated as a letter, so it can be part of the identifier (and I see it at the end of the identifier that does not prohibit the rule ).
• I needed only one typedef.
• I prefer Foo* myFoo1; by Foo *myFoo1; for several reasons, and it goes well with Foo_ myFoo2 .

When you need typedefs for different kinds of smart pointers, I would go for

 typedef shared_ptr<Foo> Foo_S; typedef weak_ptr<Foo> Foo_W; typedef unique_ptr<Foo> Foo_U; // usage examples: Foo* myFoo2; Foo_S myFoo3; Foo_W myFoo4; Foo_U myFoo5; 

With the increasing support for Unicode in compiler standards and implementations, I will be tempted to try the following syntax, assuming that these star characters will be treated as a regular part of the type identifier. Of course, this is practical if for all involved developers there is a convenient way to enter text:

 typedef shared_ptr<Foo> Foo★; typedef weak_ptr<Foo> Foo☆; typedef unique_ptr<Foo> Foo✪; // usage examples: Foo* myFoo6; Foo★ myFoo7; Foo☆ myFoo8; Foo✪ myFoo9; 

(A quick test showed that this really does not work, at least with my build environment. But the same is true for Foo_ä .)

Answer 2

Answer: do not do this. It is convenient for you and for someone else. Say what you mean.

Answer 3

My preferences:

 class Foo { public: typedef boost::shared_ptr<Foo> SharedPointer; }; 

The only problem with FooPtr is that you can have different types of pointers (e.g. weak_ptr s). I also do not really like contractions, but this is a completely different matter.

Answer 4

Personally, in the code for which I am responsible, you usually see FooPtr typedef'd in the same area of ​​the namespace as Foo, and Foo will contain a typed "SmartPtr" typedef for the same type as FooPtr. With FooPtr, you can easily use tacit manual use. the presence of a nested typedef for "SmartPtr" or some "even" allows simple general use in templates, macros, etc., without knowing this actual type of smart pointer.

In addition, I would suggest adding a “subjective” tag to this question.

Answer 5

I used both an external and an encapsulated typedef, but ended up being the first,

 typedef boost::shared_ptr<Foo> FooPtr; 

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

Does it bother you that Foo is now “aware” of how it will be transmitted?

Quite often, these classes are only created using the factory method:

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

Such a “stronger” than typedef encapsulation, but a very general pattern.

Answer 6

I am 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 not to be a big problem. In any case, I would definitely point to it, in particular, to a general pointer, especially if you are not the only one who will use this type in the future.

Answer 7

I usually encapsulate a typedef inside a 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 what the class should support, it makes sense that I know what common the separator to use will be wrapped in the class.

Answer 8

My first answer is to ask: "Why is typedef this?"

In response to your editing: this is actually a pretty interesting approach that can be useful in many situations. Using it to return to the original question, you can:

 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 9

I'm not really a fan of very short identifiers, but this is one case when I will use them.

 class Foo { public: typedef std::shared_ptr<Foo> p; }; 

This allows shared_ptr to resemble regular pointers as closely as possible without the risk of confusion.

 Foo* myFoo; Foo::p myFoo; 

As for the encapsulation gap - no, then typedefing the type shared_ptr inside the class does not violate encapsulation no more than it types it outside the class. What meaning of "encapsulation" would be violated? You do not reveal anything about the implementation of Foo. You just define the type. This is exactly the same as the relationship between Foo * and Foo. Foo * is a specific type of pointer to Foo (by default, as it happens). Foo :: p is another kind of pointer to Foo. You do not break encapsulation, you just add a type system.

Answer 10

 class foo; typedef boost::shared_ptr<foo> foo_p; typedef boost::weak_ptr<foo> foo_wp; 

Answer 11

  typedef shared_ptr<Foo> sptr_Foo; typedef weak_ptr<Foo> wptr_Foo; typedef unique_ptr<Foo> uptr_Foo; 

Answer 12

Good when _t ends.

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

Answer 13

This was one of the conventions that I turned to:

 typedef boost::shared_ptr<Foo> FooProxy; 

... seeing that boost::shared_ptr is a proxy template application.

Answer 14

typedef boost::shared_ptr<MyClass> MyClass$;

Answer 15

What about:

 template <typename T> class Shared { public: typedef std::shared_ptr<T> Ptr; // or boost::shared_ptr if you will }; 

Then, so that any Shared class has its own Ptr object, as in:

 class myClass : public Shared<myClass> { }; int main() { myClass::Ptr object; //... object->foo(); } 

Answer 16

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

This clearly indicates that it is refpounted ptr.