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


Question

Something I have found myself doing often lately is declaring typedefs relevant to a particular class inside that class, i.e.

class Lorem
{
    typedef boost::shared_ptr<Lorem> ptr;
    typedef std::vector<Lorem::ptr>  vector;

//
// ...
//
};

These types are then used elsewhere in the code:

Lorem::vector lorems;
Lorem::ptr    lorem( new Lorem() );

lorems.push_back( lorem );

Reasons I like it:

  • It reduces the noise introduced by the class templates, std::vector<Lorem> becomes Lorem::vector, etc.
  • 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.
  • It allows the implementation to change - i.e. if Lorem needed to be changed to be intrusively reference counted (via boost::intrusive_ptr) at a later stage then this would have minimal impact to the code.
  • I think it looks 'prettier' and is arguably easier to read.

Reasons I don't like it:

  • There are sometimes issues with dependencies - if you want to embed, say, a Lorem::vector within another class but only need (or want) to forward declare Lorem (as opposed to introducing a dependency on its header file) then you end up having to use the explicit types (e.g. boost::shared_ptr<Lorem> rather than Lorem::ptr), which is a little inconsistent.
  • It may not be very common, and hence harder to understand?

I try to be objective with my coding style, so it would be good to get some other opinions on it so I can dissect my thinking a little bit.

1
167
4/17/2009 8:25:08 AM

Accepted Answer

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.

142
4/17/2009 8:31:03 AM

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.


Licensed under: CC-BY-SA with attribution
Not affiliated with: Stack Overflow
Icon