No really, that's the only answer.

On the one side, it's a pain to have to remember to type

std::map<somesortofKeyType, SomeSortofValue, somesortthing>::iterator

whenever you want to look in your collection of values, when "ValueIter"
would work.

OTOH, sometimes you have to chase back and find out what all those
things are.

I'm guessing you're new on the project.  Best talk to someone, and ask
them why.

identity<int[5]>::type *ptr;

I've seen that identity has lots of nice uses, where otherwise a typedef
would have to be used to make things easy to read. The above would look like
the below with typedef

typedef int array_type[5];
array_type *ptr;

"doublemaster...@gmail.com" <doublemaster...@gmail.com> spake the secret code
<72babf2c-fbba-4612-9f0a-958a37596...@f1g2000prf.googlegroups.com> thusly:

Its possible to overuse typedefs to the point where they fail to
provide value.

For instance, I personally don't find value in typedefs like this:

    typedef std::string *stringPtr;

Particularly since using that typedef leads you down the problem of
improperly specifying pointers to const strings.  People think its
this:

    const stringPtr unchangedStringThroughPointer;

Unfortunately you didn't specify the string was const, but that the
pointer was const.  That's why Windows headers have the typedefs LPSTR
and LPCSTR, with the former being pointer to char and the latter being
pointer to const char.  (The LP business is just an anachronism from
Win16 days.)  Is LPSTR really more clear than char *?  Is LPCSTR
really more clear than char const *?  I don't think so, but I'll use
those typedefs because they are pervasive in Windows and Windows
programmers are familiar enough with them to know what they mean.  I
stop short of using things like LPDIRECT3DDEVICE9 instead of
IDirect3DDevice9 *.  The former just feels like screaming to me, while
the latter is easier to read and is just as clear (in context) that
we're talking about a COM interface pointer.

I'm currently working on a code base that is replete with typedefs
like these:

    typedef unsigned char uint8;
    typedef int int32;
    typedef unsigned int uint32;
    typedef float real;
    typedef double lreal;

and so-on.

Personally I don't like declaring my types as having a bit size unless
it is truly relevant to their role.  Once *everything* is declared as
an int32, how do you know which ones *really* need 32-bits and which
ones are comfortable in the native size of int?  If you really need to
guarantee that an int is at least 32-bits you can do this in other
ways than polluting the entire source base with spurious int32's
everywhere.

The real/lreal thing is particularly annoying.  It just obfuscates the
code in an attemp to abstract away a coupling to an implementation
dependency, yet it fails to do so in any meaningful way because it is
just an alias for an implementation dependency instead of an
abstraction like a new type (i.e. a class) would do.  Because the
built-in types like int, float and double can't be extended or
customized, the typedef doesn't carry its own weight.  It obscures the
fact that you *are* coupled to the implementation details of a float
or a double, while at the same time pretending to decouple you from
those details.  It adds no value and reduces the clarity of the code.

The one area where typedefs are most useful is in consuming template
classes.  std::string::find returns std::string::size_type; if I'm
using that type repeatedly in a function its easier to create a local
typedef for it:

void wipeOutSlashes(std::string &text)
{
    typedef std::string::size_type size_type;

    // declare locals of type size_type

Just my two cents ...
In addition to what Richard wrote, sometimes typedef declaration is
almost necessary.
For example, in C++ standard library, there are a lot of typedef
declarations
inside declaration/defintion of containers. A typical typedef is a
another
name for template parameter:
   template<class T> // the bare bones
   class std::list {
     // ...
     typedef T value_type;
     // ...
   };
So, we can use the template parameter:
   void f(list<T>& L)
   {
     typename list<T>::value_type v = *v.begin();
     // ...
   }
without such typedef we can't use template parameter in generic
manner.
Also the keyword "typename" in above line is necessary.

- Most people, I think, dislike when a typedef is used to try to hide
  that something is a struct or a pointer. Like, having to type FooPtr
  instead of Foo*. I think Richard mentioned why that is not only
  annoying but also harmful.

- Projects often overuse CHAR, UCHAR, uint32, etc ... typedefs.
  Not a plain char or int in sight. I hate that.

- Typedefs are just aliases; they don't buy you type safety.
  You might have
     typedef std::string PersonName;
     typedef std::string Gender;
  and still mix up the arguments to
     void DatingService::add(const PersonName&, const Gender&);
  In other words, that prototype adds *no* value compared to
  one where the arguments are const std::string&.

Is your problem one of these?

/Jorgen

We've got an awful lot of uint32_t in our project.  That's because it
represents a data item which, because of published specifications, is 32
bits, no more, no less.

int is a word size which is convenient for the machine - good for
loopcounts, but not for precise data mappings.

<snip>

Lovely bug:-

   Station_id read_station_id (FILE *in)
   {
      Station_id station_id;
      fscanf (in, "%d", &station_id);
      return station_id;
   }

Station_id was a short.

void DatingService::add(const std::string &personName&, std::const
string& gender);

    void DatingService::add( Name const& personName,
                             Gender const& gender );

A Name is more than a string, and a Gender is most likely an
enum.

But what should I use if I want to represent a guaranteed-to-be-32-bit
quantity?

I found a few of these while porting a project from VC++ to gcc. gcc has
an option to check printf-type format strings.

http://www.unisys.com/clearpath

Requiring them to have a uint32_t would be REALLY expensive. To top it
off, these machines also have 9-bit bytes, one's complement
arithmetic, and 72-bit non-IEEE floating point.  :-)

Unlike Java, C++ could actually be implemented.