Internal typedefs in C++ - good style or bad style?

Question

I think it is excellent style, and I use it myself. It is always best to limit the scope of names as much as possible, and use of classes is the best way to do this in C++. For example, the C++ Standard library makes heavy use of typedefs within classes.

It serves as a statement of intent - in the example above, the Lorem class is intended to be reference counted via boost::shared_ptr and stored in a vector.

This is exactly what it does not do.

If I see 'Foo::Ptr' in the code, I have absolutely no idea whether it's a shared_ptr or a Foo* (STL has ::pointer typedefs that are T*, remember) or whatever. Esp. if it's a shared pointer, I don't provide a typedef at all, but keep the shared_ptr use explicitly in the code.

Actually, I hardly ever use typedefs outside Template Metaprogramming.

The STL does this type of thing all the time

The STL design with concepts defined in terms of member functions and nested typedefs is a historical cul-de-sac, modern template libraries use free functions and traits classes (cf. Boost.Graph), because these do not exclude built-in types from modelling the concept and because it makes adapting types that were not designed with the given template libraries' concepts in mind easier.

Don't use the STL as a reason to make the same mistakes.

Typedefs are the ones what policy based design and traits built upon in C++, so The power of Generic Programming in C++ stems from typedefs themselves.

Typdefs are definitely are good style. And all your "reasons I like" are good and correct.

About problems you have with that. Well, forward declaration is not a holy grail. You can simply design your code to avoid multi level dependencies.

You can move typedef outside the class but Class::ptr is so much prettier then ClassPtr that I don't do this. It is like with namespaces as for me - things stay connected within the scope.

Sometimes I did

Trait<Loren>::ptr
Trait<Loren>::collection
Trait<Loren>::map

And it can be default for all domain classes and with some specialization for certain ones.

The STL does this type of thing all the time - the typedefs are part of the interface for many classes in the STL.

reference
iterator
size_type
value_type
etc...

are all typedefs that are part of the interface for various STL template classes.

Another vote for this being a good idea. I started doing this when writing a simulation that had to be efficient, both in time and space. All of the value types had an Ptr typedef that started out as a boost shared pointer. I then did some profiling and changed some of them to a boost intrusive pointer without having to change any of the code where these objects were used.

Note that this only works when you know where the classes are going to be used, and that all the uses have the same requirements. I wouldn't use this in library code, for example, because you can't know when writing the library the context in which it will be used.