The typedef policy taken by the Linux kernel for C is the best. Essentially the policy is to not use typedefs unless you are creating a new type abstraction. This is useful in cases where low-level types different among architectures, but kernel users want a common type. For example u64 is given a specific type, but the underlying type might change between builds or architectures.
typedef u64 unsigned long long;
However, it is highly likely that in C++ there are different idioms using typedefs that are perfectly acceptable, however, I would get comfortable with C before C++.
Perhaps the best way to get re-oriented with C++ is to write may one-off programs that exercise a specific feature. For example, write a template, use a library in Boost, create some threads, allocate some memory. The point isn't to learn all of this stuff, the point is to see and it so you aren't gasping for air later on when it's showtime.
Here is the Linux kernel typedef standard, taken from http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.33.y.git;a=blob_plain;f=Documentation/CodingStyle;hb=HEAD
Chapter 5: Typedefs
Please don't use things like "vps_t".
It's a mistake to use typedef for
structures and pointers. When you see
a
vps_t a;
in the source, what does it mean?
In contrast, if it says
struct virtual_container *a;
you can actually tell what "a" is.
Lots of people think that typedefs
"help readability". Not so. They are
useful only for:
(a) totally opaque objects (where the
typedef is actively used to hide
what the object is).
Example: "pte_t" etc. opaque objects that you can only access using
the proper accessor functions.
NOTE! Opaqueness and "accessor functions" are not good in themselves.
The reason we have them for things like pte_t etc. is that there
really is absolutely _zero_ portably accessible information there.
(b) Clear integer types, where the
abstraction helps avoid confusion
whether it is "int" or "long".
u8/u16/u32 are perfectly fine typedefs, although they fit into
category (d) better than here.
NOTE! Again - there needs to be a _reason_ for this. If something is
"unsigned long", then there's no reason to do
typedef unsigned long myflags_t;
but if there is a clear reason for why it under certain circumstances
might be an "unsigned int" and under other configurations might be
"unsigned long", then by all means go ahead and use a typedef.
(c) when you use sparse to literally
create a new type for
type-checking.
(d) New types which are identical to
standard C99 types, in certain
exceptional circumstances.
Although it would only take a short amount of time for the eyes and
brain to become accustomed to the standard types like 'uint32_t',
some people object to their use anyway.
Therefore, the Linux-specific 'u8/u16/u32/u64' types and their
signed equivalents which are identical to standard types are
permitted -- although they are not mandatory in new code of your
own.
When editing existing code which already uses one or the other set
of types, you should conform to the existing choices in that code.
(e) Types safe for use in userspace.
In certain structures which are visible to userspace, we cannot
require C99 types and cannot use the 'u32' form above. Thus, we
use __u32 and similar types in all structures which are shared
with userspace.
Maybe there are other cases too, but
the rule should basically be to NEVER
EVER use a typedef unless you can
clearly match one of those rules.
In general, a pointer, or a struct
that has elements that can reasonably
be directly accessed should never be
a typedef.
