good to have typedef?

Discussion in 'C++' started by doublemaster007@gmail.com, Oct 30, 2009.

  1. Guest

    Is it good to typedef the types?? What is the actual use of it? I am
    working on project where tooo many typedefs are used..If many people
    are working on a project..only the person who defined will be
    remembering it..finally too many typedefs will be there and code
    becomes hard to use...

    So i wanna know..is typedefs are really useful in full fledged
    project??
    , Oct 30, 2009
    #1
    1. Advertising

  2. wrote:

    > Is it good to typedef the types?? What is the actual use of it? I am
    > working on project where tooo many typedefs are used..If many people
    > are working on a project..only the person who defined will be
    > remembering it..finally too many typedefs will be there and code
    > becomes hard to use...
    >

    Sometimes, you can make better use of identity than of typedef. For example
    to make a pointer to an array, and you want to use a typedef, you can
    instead use identity

    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;

    And i think using identity, this looks and feels better.
    Johannes Schaub (litb), Oct 30, 2009
    #2
    1. Advertising

  3. Richard Guest

    [Please do not mail me a copy of your followup]

    "" <> spake the secret code
    <> thusly:

    >So i wanna know..is typedefs are really useful in full fledged
    >project??


    Like anything in your code, you should use them if they add value and
    avoid them if they are not carrying their weight.

    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
    }

    That's just a simple example. It gets more useful when declaring
    iterators and other types related to a template class. If you are
    writing template libraries, creating nested typedefs that refer to
    related types in your base class or in the template argument are very
    useful for making the template expansion more readable.
    --
    "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
    <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

    Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
    Richard, Oct 31, 2009
    #3
  4. On Oct 31, 12:01 am, ""
    <> wrote:
    > Is it good to typedef the types?? What is the actual use of it? I am
    > working on project where tooo many typedefs are used..If many people
    > are working on a project..only the person who defined will be
    > remembering it..finally too many typedefs will be there and code
    > becomes hard to use...
    >
    > So i wanna know..is typedefs are really useful in full fledged
    > project??


    Hi

    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.

    Regards,
    -- Saeed Amrollahi
    Saeed Amrollahi, Oct 31, 2009
    #4
  5. Jorgen Grahn Guest

    On Fri, 2009-10-30, wrote:
    > Is it good to typedef the types?? What is the actual use of it? I am
    > working on project where tooo many typedefs are used..If many people
    > are working on a project..only the person who defined will be
    > remembering it..finally too many typedefs will be there and code
    > becomes hard to use...


    I have to say that doesn't make sense to me. It's hard to see what
    the problem is with your code.

    > So i wanna know..is typedefs are really useful in full fledged
    > project??


    I agree with "Richard" elsewhere in this thread. And also:

    - 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

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Nov 4, 2009
    #5
  6. James Kanze Guest

    On Nov 4, 11:06 pm, Andy Champ <> wrote:
    > Jorgen Grahn wrote:


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


    > </snip>


    > 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.


    I'm curious. What published specifications impose anything
    concerning the internal representation? (Externally, of course,
    the published specifications probably impose more than just 32
    bits. Like byte order, for example.)

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


    That's not it's role. When you need to input or output data in
    a precise format, you write code to do so: int32_t and others
    aren't directly applicable here. (Indirectly... if you're
    willing to restrict your portability to machines where uint32_t
    is available---and that's still a lot of them---, then using it
    for certain intermediate representations can make your code
    significantly simpler.)

    --
    James Kanze
    James Kanze, Nov 5, 2009
    #6
  7. On 4 Nov, 22:19, Jorgen Grahn <> wrote:
    > On Fri, 2009-10-30, wrote:


    > > Is it good to typedef the types?? What is the actual use of it? I am
    > > working on project where tooo many typedefs are used..If many people
    > > are working on a project..only the person who defined will be
    > > remembering it..finally too many typedefs will be there and code
    > > becomes hard to use...


    get a decent source browser. I agree typedefs can be over-used but the
    they can be under-used as well.

    <snip>

    > - Most people, I think, dislike when a typedef is used to try to hide
    >   that something is a struct or a pointer.


    I've no objection to hiding a struct behind a typedef (or at least in
    C becasue I hate scattering the "struct" keyword all over the place
    (I'm aware C++ doesn't have this problem)). I'm almost with you on
    pointers except I justify hungarian for smart pointers. This is one of
    the few places I'd advocate hungarian because I /want/ my nose rubbed
    in what-type-of-pointer is this to make sure I cleanup properly.


    > Like, having to type FooPtr
    >   instead of Foo*. I think Richard mentioned why that is not only
    >   annoying but also harmful.


    oh, I agree. Then there's hiding arrays (but C++ programmers don't use
    arrays :) )


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


    yuk. I've worked on projects where the programmming standards said you
    must not use raw types. And the configuration control system
    checked. :-(

    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.


    > - Typedefs are just aliases; they don't buy you type safety.


    too true. Possibly one of C's design mistakes.

    >   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&.


    it documents intent. I'd maybe write

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


    > Is your problem one of these?
    Nick Keighley, Nov 5, 2009
    #7
  8. James Kanze Guest

    On Nov 5, 9:31 pm, Andy Champ <> wrote:
    > James Kanze wrote:


    > > I'm curious. What published specifications impose anything
    > > concerning the internal representation? (Externally, of
    > > course, the published specifications probably impose more
    > > than just 32 bits. Like byte order, for example.)


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


    > > That's not it's role. When you need to input or output data
    > > in a precise format, you write code to do so: int32_t and
    > > others aren't directly applicable here. (Indirectly... if
    > > you're willing to restrict your portability to machines
    > > where uint32_t is available---and that's still a lot of
    > > them---, then using it for certain intermediate
    > > representations can make your code significantly simpler.)


    > You've answered your own question - it's a data transfer
    > specification.


    In which case, uint32_t doesn't necessarily buy you that much.
    (It does restrict portability, however, since it is guaranteed
    not to be available on some machines.)

    --
    James Kanze
    James Kanze, Nov 5, 2009
    #8
  9. James Kanze Guest

    On Nov 5, 10:57 am, Nick Keighley <>
    wrote:
    > On 4 Nov, 22:19, Jorgen Grahn <> wrote:


    [...]
    > > 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&.


    > it documents intent. I'd maybe write


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


    Why not:

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

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

    --
    James Kanze
    James Kanze, Nov 5, 2009
    #9
  10. Ian Collins Guest

    Andy Champ wrote:
    > James Kanze wrote:
    >>
    >> In which case, uint32_t doesn't necessarily buy you that much.
    >> (It does restrict portability, however, since it is guaranteed
    >> not to be available on some machines.)

    >
    > Luckily for _me_ I only need to worry about Windoze boxes - albeit 64
    > bit is likely to come up soon. And I'm also lucky that my byte order
    > matches the spec. - not everyone does the ISO 9660 trick of storing a
    > number in both common orders, it's not space efficient!
    >
    > But what should I use if I want to represent a guaranteed-to-be-32-bit
    > quantity?


    uint32_t if the system has it. If not, define your own.

    --
    Ian Collins
    Ian Collins, Nov 6, 2009
    #10
  11. James Kanze Guest

    On Nov 6, 3:47 am, Ian Collins <> wrote:
    > Andy Champ wrote:
    > > James Kanze wrote:


    > >> In which case, uint32_t doesn't necessarily buy you that
    > >> much. (It does restrict portability, however, since it is
    > >> guaranteed not to be available on some machines.)


    > > Luckily for _me_ I only need to worry about Windoze boxes -
    > > albeit 64 bit is likely to come up soon. And I'm also lucky
    > > that my byte order matches the spec. - not everyone does the
    > > ISO 9660 trick of storing a number in both common orders,
    > > it's not space efficient!


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


    > uint32_t if the system has it. If not, define your own.


    If he only has to worry about Windows, the system has it. On
    systems which don't have it, however, defining your own might be
    a bit difficult, and the type will probably be significantly
    slower than one of the built-in types. (On at least one system,
    the built-in unsigned types are significantly slower than the
    the signed ones, because the hardware doesn't directly support
    them.)

    --
    James Kanze
    James Kanze, Nov 6, 2009
    #11
  12. James Kanze wrote:

    > On Nov 6, 3:47 am, Ian Collins <> wrote:
    >> Andy Champ wrote:
    >>> James Kanze wrote:

    >
    >>>> In which case, uint32_t doesn't necessarily buy you that much. (It
    >>>> does restrict portability, however, since it is guaranteed not to
    >>>> be available on some machines.)

    >
    >>> Luckily for _me_ I only need to worry about Windoze boxes - albeit
    >>> 64 bit is likely to come up soon. And I'm also lucky that my byte
    >>> order matches the spec. - not everyone does the ISO 9660 trick of
    >>> storing a number in both common orders, it's not space efficient!

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

    >
    >> uint32_t if the system has it. If not, define your own.

    >
    > If he only has to worry about Windows, the system has it. On systems
    > which don't have it, however, defining your own might be a bit
    > difficult, and the type will probably be significantly slower than
    > one of the built-in types. (On at least one system, the built-in
    > unsigned types are significantly slower than the the signed ones,
    > because the hardware doesn't directly support them.)


    I'm curious... what system doesn't "have" a uint32_t? I work also on
    small 8bit micros (in C, but that's not really the issue here), and if I
    really need it, I can use a uint32_t. It's not a native word size on
    those systems, but the compiler couldn't care less about that. (Well,
    the compiler writer of course does, and I do, too, where performance and
    resources are an issue -- but the system "has it".)

    Gerhard
    Gerhard Fiedler, Nov 7, 2009
    #12
  13. Nick Keighley wrote:

    > 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.


    You should get a compiler or linter that checks for such things -- or
    use C++ streams in the first place :)

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

    Gerhard
    Gerhard Fiedler, Nov 7, 2009
    #13
  14. Bo Persson Guest

    Gerhard Fiedler wrote:
    > James Kanze wrote:
    >
    >> On Nov 6, 3:47 am, Ian Collins <> wrote:
    >>> Andy Champ wrote:
    >>>> James Kanze wrote:

    >>
    >>>>> In which case, uint32_t doesn't necessarily buy you that much.
    >>>>> (It does restrict portability, however, since it is guaranteed
    >>>>> not to be available on some machines.)

    >>
    >>>> Luckily for _me_ I only need to worry about Windoze boxes -
    >>>> albeit 64 bit is likely to come up soon. And I'm also lucky
    >>>> that my byte order matches the spec. - not everyone does the ISO
    >>>> 9660 trick of storing a number in both common orders, it's not
    >>>> space efficient!

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

    >>
    >>> uint32_t if the system has it. If not, define your own.

    >>
    >> If he only has to worry about Windows, the system has it. On
    >> systems which don't have it, however, defining your own might be a
    >> bit difficult, and the type will probably be significantly slower
    >> than one of the built-in types. (On at least one system, the
    >> built-in unsigned types are significantly slower than the the
    >> signed ones, because the hardware doesn't directly support them.)

    >
    > I'm curious... what system doesn't "have" a uint32_t? I work also on
    > small 8bit micros (in C, but that's not really the issue here), and
    > if I really need it, I can use a uint32_t. It's not a native word
    > size on those systems, but the compiler couldn't care less about
    > that. (Well, the compiler writer of course does, and I do, too,
    > where performance and resources are an issue -- but the system "has
    > it".)
    >


    Systems like these, that are based on 36-bit hardware

    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.


    Bo Persson
    Bo Persson, Nov 7, 2009
    #14
  15. James Kanze Guest

    On Nov 7, 7:44 pm, Gerhard Fiedler <> wrote:
    > James Kanze wrote:
    > > On Nov 6, 3:47 am, Ian Collins <> wrote:
    > >> Andy Champ wrote:
    > >>> James Kanze wrote:


    > >>>> In which case, uint32_t doesn't necessarily buy you that
    > >>>> much. (It does restrict portability, however, since it
    > >>>> is guaranteed not to be available on some machines.)


    > >>> Luckily for _me_ I only need to worry about Windoze boxes
    > >>> - albeit 64 bit is likely to come up soon. And I'm also
    > >>> lucky that my byte order matches the spec. - not everyone
    > >>> does the ISO 9660 trick of storing a number in both common
    > >>> orders, it's not space efficient!


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


    > >> uint32_t if the system has it. If not, define your own.


    > > If he only has to worry about Windows, the system has it.
    > > On systems which don't have it, however, defining your own
    > > might be a bit difficult, and the type will probably be
    > > significantly slower than one of the built-in types. (On at
    > > least one system, the built-in unsigned types are
    > > significantly slower than the the signed ones, because the
    > > hardware doesn't directly support them.)


    > I'm curious... what system doesn't "have" a uint32_t?


    Neither of the Unisys mainframe architectures: one's 36 bit ones
    complement, the other 48 bit signed magnitude (with 8 bits
    reserved).

    > I work also on small 8bit micros (in C, but that's not really
    > the issue here), and if I really need it, I can use a
    > uint32_t. It's not a native word size on those systems, but
    > the compiler couldn't care less about that. (Well, the
    > compiler writer of course does, and I do, too, where
    > performance and resources are an issue -- but the system "has
    > it".)


    The compiler has to provide 32 bit arithmetic somehow, and if
    the machine is 8 bits, using 32 bits for long, rather than more,
    is the preferred solution. The problems are more with larger
    machines, where the machine word size is 36 or 48 bits (or in
    the past, 60 bits)---at one time, 36 bits was quite common.

    --
    James Kanze
    James Kanze, Nov 9, 2009
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. sikka noel
    Replies:
    8
    Views:
    418
    Mike Wahler
    Aug 5, 2003
  2. marco
    Replies:
    2
    Views:
    352
    marco
    Sep 2, 2004
  3. Eric Lilja
    Replies:
    3
    Views:
    344
    Alf P. Steinbach
    Mar 6, 2005
  4. dreamcatcher

    is it any good to use typedef ?

    dreamcatcher, Sep 19, 2003, in forum: C Programming
    Replies:
    14
    Views:
    691
    John Bode
    Sep 23, 2003
  5. oor
    Replies:
    0
    Views:
    1,346
Loading...

Share This Page