Regarding typedef and macro

Discussion in 'C Programming' started by sam_cit@yahoo.co.in, Dec 13, 2006.

  1. Guest

    I noticed that what is being done by typedef can very much be done by
    macro, and i also think there must be a specific reason as to why
    typedef was introduced,
    what is the exact difference, and are there any reasons that we should
    prefer one over the other and how is typedef internally implemented?
     
    , Dec 13, 2006
    #1
    1. Advertising

  2. said:

    > I noticed that what is being done by typedef can very much be done by
    > macro, and i also think there must be a specific reason as to why
    > typedef was introduced,
    > what is the exact difference, and are there any reasons that we should
    > prefer one over the other and how is typedef internally implemented?


    The exact difference is that typedef creates a synonym for an existing type,
    whereas macros cause pp-token substitution to occur.

    You should prefer typedef when you want a synonym for an existing type, but
    you should prefer macros when you want pp-token substitution to occur.

    The internal implementation of typedef is up to the implementor. There Is
    More Than One Way To Do It.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at the above domain, - www.
     
    Richard Heathfield, Dec 13, 2006
    #2
    1. Advertising

  3. Richard Bos Guest

    wrote:

    > I noticed that what is being done by typedef can very much be done by
    > macro, and i also think there must be a specific reason as to why
    > typedef was introduced,
    > what is the exact difference, and are there any reasons that we should
    > prefer one over the other and how is typedef internally implemented?


    A typedef is a proper type. A macro is a text substitution. There may
    not seem to be much difference between typedef int number and #define
    number int, but you try this:

    #define pointer1 int *
    typedef int * pointer2;

    pointer1 a, b;
    pointer2 c, d;

    How many pointers?

    Richard
     
    Richard Bos, Dec 13, 2006
    #3
  4. (Richard Bos) writes:
    [...]
    > A typedef is a proper type.

    [...]

    For certain values of "proper". A typedef creates an alias for an
    existing type; it doesn't create a new type.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Dec 13, 2006
    #4
  5. On 12 Dec 2006 23:26:58 -0800, wrote:

    >I noticed that what is being done by typedef can very much be done by
    >macro, and i also think there must be a specific reason as to why


    Convert
    typedef struct s1{
    int m1;
    struct s1 *m2;
    } t1;
    to a macro and then try to define two structure objects.

    >typedef was introduced,
    >what is the exact difference, and are there any reasons that we should
    >prefer one over the other and how is typedef internally implemented?



    Remove del for email
     
    Barry Schwarz, Dec 13, 2006
    #5
  6. Eric Sosman Guest

    wrote:
    > I noticed that what is being done by typedef can very much be done by
    > macro, and i also think there must be a specific reason as to why
    > typedef was introduced,
    > what is the exact difference, and are there any reasons that we should
    > prefer one over the other and how is typedef internally implemented?


    The canonical example of non-equivalence looks like

    typedef char *CharPtr;
    CharPtr p1, p2;

    #define CHARPTR char *
    CHARPTR q1, q2;

    Once you've studied that one for a while, try this
    challenge:

    typedef double Matrix[4][4];
    Matrix m1, m2;

    #define MATRIX /* supply macro definition */
    MATRIX x1, x2;

    .... where your task is to provide a definition of MATRIX
    that makes x1,x2 have the same type as m1,m2. (It is, of
    course, considered cheating to use a typedef'ed name in
    the expansion of MATRIX; the point of the exercise is to
    discover something typedef can do easily that is difficult
    to handle with unaided macro substitution.)

    However, typedef is not all-powerful. Consider

    #include <limits.h>
    #if INT_MAX >= 1000000
    typedef int Million;
    #else
    typedef long Million;
    #endif
    Million s1;
    unsigned Million u1; /* illegal! */

    #if INT_MAX >= 1000000
    #define MILLION int
    #else
    #define MILLION long
    #endif
    MILLION s2;
    unsigned MILLION u2; /* legal (albeit dumb) */

    --
    Eric Sosman
    lid
     
    Eric Sosman, Dec 13, 2006
    #6
  7. wrote:
    >
    > I noticed that what is being done by typedef can very much be done by
    > macro, and i also think there must be a specific reason as to why
    > typedef was introduced,
    > what is the exact difference, and are there any reasons that we should
    > prefer one over the other and how is typedef internally implemented?


    Perhaps the easiest way to think of this is to consider pointers,
    and the difference between:

    typedef char *CharPointer;
    and
    #define CharPointer char *

    Specifically in the case of:

    CharPointer pt1, pt2;

    Also, type checking can be better enforced with typedefs than with
    #defines. If you #define a new "type", the comipler has no way of
    knowing the difference between your "type" and the base type. But,
    with typedefs, your new type is treated as a distinct type. For
    example:

    typedef long MyLong;

    The compiler can treat "MyLong" and "long" as two distinct types,
    whereas in this case:

    #define MyLong long

    there is no distinction possible.

    --
    +-------------------------+--------------------+-----------------------+
    | Kenneth J. Brody | www.hvcomputer.com | #include |
    | kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------+
    Don't e-mail me at: <mailto:>
     
    Kenneth Brody, Dec 13, 2006
    #7
  8. Eric Sosman Guest

    Kenneth Brody wrote:
    > [...]
    > Also, type checking can be better enforced with typedefs than with
    > #defines. If you #define a new "type", the comipler has no way of
    > knowing the difference between your "type" and the base type. But,
    > with typedefs, your new type is treated as a distinct type. For
    > example:
    >
    > typedef long MyLong;
    >
    > The compiler can treat "MyLong" and "long" as two distinct types,
    > [...]


    Since MyLong and long are the *same* type, a compiler that
    gives them different "effective" treatment is broken. A compiler
    or lint-like utility might issue warning messages -- a compiler
    can issue warning messages about the phase of the moon -- but
    a program using a MyLong in some context must have exactly the
    same behavior as if a long were used instead.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Dec 13, 2006
    #8
  9. Random832 Guest

    2006-12-13 <>,
    Kenneth Brody wrote:
    ] [ blah, #define CharPointer char *, blah, CharPointer pt1, pt2; ]

    True.

    > typedef long MyLong;
    > The compiler can treat "MyLong" and "long" as two distinct types,


    False.
     
    Random832, Dec 13, 2006
    #9
  10. Eric Sosman wrote:
    >
    > Kenneth Brody wrote:
    > > [...]
    > > Also, type checking can be better enforced with typedefs than with
    > > #defines. If you #define a new "type", the comipler has no way of
    > > knowing the difference between your "type" and the base type. But,
    > > with typedefs, your new type is treated as a distinct type. For
    > > example:
    > >
    > > typedef long MyLong;
    > >
    > > The compiler can treat "MyLong" and "long" as two distinct types,
    > > [...]

    >
    > Since MyLong and long are the *same* type, a compiler that
    > gives them different "effective" treatment is broken. A compiler
    > or lint-like utility might issue warning messages -- a compiler
    > can issue warning messages about the phase of the moon -- but
    > a program using a MyLong in some context must have exactly the
    > same behavior as if a long were used instead.


    Okay, I stand corrected.

    What I _meant_ to say was that, for the purposes of type checking,
    it can issue a warning if a prototype specifies MyLong as the type,
    but you pass long (or anything else typedef'ed to long) instead,
    as "MyLong" and "long" are distinct as far as type checking is
    concerned.

    Did I get it right this time?

    --
    +-------------------------+--------------------+-----------------------+
    | Kenneth J. Brody | www.hvcomputer.com | #include |
    | kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------+
    Don't e-mail me at: <mailto:>
     
    Kenneth Brody, Dec 13, 2006
    #10
  11. Eric Sosman <> writes:
    [...]
    > However, typedef is not all-powerful. Consider
    >
    > #include <limits.h>
    > #if INT_MAX >= 1000000
    > typedef int Million;
    > #else
    > typedef long Million;
    > #endif
    > Million s1;
    > unsigned Million u1; /* illegal! */
    >
    > #if INT_MAX >= 1000000
    > #define MILLION int
    > #else
    > #define MILLION long
    > #endif
    > MILLION s2;
    > unsigned MILLION u2; /* legal (albeit dumb) */


    Yup. But if I really wanted to do something like that, I'd write it
    this way:

    #include <limits.h>
    #if INT_MAX >= 1000000
    typedef int Million;
    typedef unsigned int Unsigned_Million;
    #else
    typedef long Million;
    typedef unsigned long Unsigned_Million;
    #endif
    Million s1;
    Unsigned_Million u1;

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Dec 13, 2006
    #11
  12. Kenneth Brody <> writes:
    > Eric Sosman wrote:
    >>
    >> Kenneth Brody wrote:
    >> > [...]
    >> > Also, type checking can be better enforced with typedefs than with
    >> > #defines. If you #define a new "type", the comipler has no way of
    >> > knowing the difference between your "type" and the base type. But,
    >> > with typedefs, your new type is treated as a distinct type. For
    >> > example:
    >> >
    >> > typedef long MyLong;
    >> >
    >> > The compiler can treat "MyLong" and "long" as two distinct types,
    >> > [...]

    >>
    >> Since MyLong and long are the *same* type, a compiler that
    >> gives them different "effective" treatment is broken. A compiler
    >> or lint-like utility might issue warning messages -- a compiler
    >> can issue warning messages about the phase of the moon -- but
    >> a program using a MyLong in some context must have exactly the
    >> same behavior as if a long were used instead.

    >
    > Okay, I stand corrected.
    >
    > What I _meant_ to say was that, for the purposes of type checking,
    > it can issue a warning if a prototype specifies MyLong as the type,
    > but you pass long (or anything else typedef'ed to long) instead,
    > as "MyLong" and "long" are distinct as far as type checking is
    > concerned.
    >
    > Did I get it right this time?


    Yes, but I'd be (mildly) surprised if a compiler actually issued such
    a warning.

    Typedefs really don't create new types; they just create new names for
    existing types.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Dec 13, 2006
    #12
  13. Eric Sosman Guest

    Kenneth Brody wrote:
    > Eric Sosman wrote:
    >> Kenneth Brody wrote:
    >>> [...]
    >>> Also, type checking can be better enforced with typedefs than with
    >>> #defines. If you #define a new "type", the comipler has no way of
    >>> knowing the difference between your "type" and the base type. But,
    >>> with typedefs, your new type is treated as a distinct type. For
    >>> example:
    >>>
    >>> typedef long MyLong;
    >>>
    >>> The compiler can treat "MyLong" and "long" as two distinct types,
    >>> [...]

    >> Since MyLong and long are the *same* type, a compiler that
    >> gives them different "effective" treatment is broken. A compiler
    >> or lint-like utility might issue warning messages -- a compiler
    >> can issue warning messages about the phase of the moon -- but
    >> a program using a MyLong in some context must have exactly the
    >> same behavior as if a long were used instead.

    >
    > Okay, I stand corrected.
    >
    > What I _meant_ to say was that, for the purposes of type checking,
    > it can issue a warning if a prototype specifies MyLong as the type,
    > but you pass long (or anything else typedef'ed to long) instead,
    > as "MyLong" and "long" are distinct as far as type checking is
    > concerned.
    >
    > Did I get it right this time?


    As far as I can tell, yes. But any such warning falls under
    the general heading of "compiler's discretion:" it can warn about
    the phase of the moon, the lack or oversufficiency of comments,
    your indenting style, or even spellnig errors in your identifiers.
    It can warn and warn all day long, but (barring actual errors) it
    must accept the program anyhow -- and if MyLong and YourLong are
    typedef'ed aliases for long, they are interchangeable.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Dec 13, 2006
    #13
  14. Eric Sosman wrote:
    >
    > Kenneth Brody wrote:

    [...]
    > > Okay, I stand corrected.
    > >
    > > What I _meant_ to say was that, for the purposes of type checking,
    > > it can issue a warning if a prototype specifies MyLong as the type,
    > > but you pass long (or anything else typedef'ed to long) instead,
    > > as "MyLong" and "long" are distinct as far as type checking is
    > > concerned.
    > >
    > > Did I get it right this time?

    >
    > As far as I can tell, yes. But any such warning falls under
    > the general heading of "compiler's discretion:" it can warn about
    > the phase of the moon, the lack or oversufficiency of comments,
    > your indenting style, or even spellnig errors in your identifiers.
    > It can warn and warn all day long, but (barring actual errors) it
    > must accept the program anyhow -- and if MyLong and YourLong are
    > typedef'ed aliases for long, they are interchangeable.


    Isn't it nice how one can program in C for over 20 years and still
    have some misconceptions, probably learned long ago and never
    unlearned?

    --
    +-------------------------+--------------------+-----------------------+
    | Kenneth J. Brody | www.hvcomputer.com | #include |
    | kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------+
    Don't e-mail me at: <mailto:>
     
    Kenneth Brody, Dec 15, 2006
    #14
  15. Random832 Guest

    2006-12-15 <>,
    Kenneth Brody wrote:
    > Eric Sosman wrote:
    >>
    >> Kenneth Brody wrote:

    > [...]
    >> > Okay, I stand corrected.
    >> >
    >> > What I _meant_ to say was that, for the purposes of type checking,
    >> > it can issue a warning if a prototype specifies MyLong as the type,
    >> > but you pass long (or anything else typedef'ed to long) instead,
    >> > as "MyLong" and "long" are distinct as far as type checking is
    >> > concerned.
    >> >
    >> > Did I get it right this time?

    >>
    >> As far as I can tell, yes. But any such warning falls under
    >> the general heading of "compiler's discretion:" it can warn about
    >> the phase of the moon, the lack or oversufficiency of comments,
    >> your indenting style, or even spellnig errors in your identifiers.
    >> It can warn and warn all day long, but (barring actual errors) it
    >> must accept the program anyhow -- and if MyLong and YourLong are
    >> typedef'ed aliases for long, they are interchangeable.

    >
    > Isn't it nice how one can program in C for over 20 years and still
    > have some misconceptions, probably learned long ago and never
    > unlearned?


    Can you provide a standard cite for your claim that this is not the
    case?
     
    Random832, Dec 15, 2006
    #15
  16. Eric Sosman Guest

    [OT] Re: Regarding typedef and macro

    Kenneth Brody wrote:
    > Eric Sosman wrote:
    >> Kenneth Brody wrote:

    > [...]
    >>> Okay, I stand corrected.
    >>>
    >>> What I _meant_ to say was that, for the purposes of type checking,
    >>> it can issue a warning if a prototype specifies MyLong as the type,
    >>> but you pass long (or anything else typedef'ed to long) instead,
    >>> as "MyLong" and "long" are distinct as far as type checking is
    >>> concerned.
    >>>
    >>> Did I get it right this time?

    >> As far as I can tell, yes. But any such warning falls under
    >> the general heading of "compiler's discretion:" it can warn about
    >> the phase of the moon, the lack or oversufficiency of comments,
    >> your indenting style, or even spellnig errors in your identifiers.
    >> It can warn and warn all day long, but (barring actual errors) it
    >> must accept the program anyhow -- and if MyLong and YourLong are
    >> typedef'ed aliases for long, they are interchangeable.

    >
    > Isn't it nice how one can program in C for over 20 years and still
    > have some misconceptions, probably learned long ago and never
    > unlearned?


    I have fifty percent more misconceptions than you do.
    Nyahh-nya-nyahh-nya-nyahh-nyaah!

    (Or, as Mark Twain almost said, one lifetime is not
    enough to master the C language.)

    --
    Eric Sosman
    lid
     
    Eric Sosman, Dec 15, 2006
    #16
    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. Oskars Salnins

    Regarding typedef

    Oskars Salnins, Apr 19, 2005, in forum: C Programming
    Replies:
    4
    Views:
    527
  2. regarding typedef

    , Mar 25, 2006, in forum: C Programming
    Replies:
    14
    Views:
    538
    CBFalconer
    Mar 29, 2006
  3. oor
    Replies:
    0
    Views:
    1,411
  4. Tagore

    typedef v/s macro

    Tagore, Dec 24, 2008, in forum: C Programming
    Replies:
    1
    Views:
    1,563
    Keith Thompson
    Dec 24, 2008
  5. Uno

    typedef v macro

    Uno, Dec 1, 2010, in forum: C Programming
    Replies:
    3
    Views:
    441
    Keith Thompson
    Dec 5, 2010
Loading...

Share This Page