Operational and functional differences - #define vs typedef ?

[O Plameras]

Are there differences in terms of functionality
of,

#define
and
typedef ?

By the above I mean any instance when the outcome
obtained by running two versions (1) and (2) below
of C codes are different ?

For example,

(1) In one C code, it has:

#define u_ unsigned
#define uc_ unsigned char

(2) The same C code is re-writtened to:

typedef unsigned u_;
typdef unsigned char uc_;

TIA.

O Plameras

 

[Keith Thompson]

Are there differences in terms of functionality
of,

#define
and
typedef ?

By the above I mean any instance when the outcome
obtained by running two versions (1) and (2) below
of C codes are different ?

For example,

(1) In one C code, it has:

#define u_ unsigned
#define uc_ unsigned char

(2) The same C code is re-writtened to:

typedef unsigned u_;
typdef unsigned char uc_;

#define creates a macro. It's expanded literally at each point where
it's used. Most syntax checking and parsing occurs *after* macros are
expanded.

A typedef creates an alias for a type. Macros and typedefs can be
used similarly, but they're really completely different things.

For example, given:
#define u_ unsigned
you can then declare
_u long x;
because the "_u" expands to "unsigned" before the type name
"unsigned long" is parsed.

In general, typedefs are better than macros for defining type aliases,
because that's what they're designed for, and because the syntax of
type declarations is such that a macro isn't always going to work.

In this particular case, I'd recommend using neither macros nor
typedefs. Someone reading your code is going to know what "unsigned"
and "unsigned char" mean. He won't know what "u_" and "uc_" mean
unless he looks up your typedef.

The names "unsigned" and "unsigned char" are perfectly clear; there's
no benefit in inventing other names for them. (Saving keystrokes
isn't much of a benefit, especially when it makes your code more
difficult to understand.)

 

[bluejack]

In this particular case, I'd recommend using neither macros nor
typedefs. Someone reading your code is going to know what "unsigned"
and "unsigned char" mean. He won't know what "u_" and "uc_" mean
unless he looks up your typedef.

How do you feel about using typedefs to ensure consistency across
platforms,
as in the case of establishing int32_t and int64_t types? (Naturally,
that requires
putting your typedef definitions within preprocessor conditionals that
ascertain
the nature of the platform...)

-bluejack

 

[pete]

Are there differences in terms of functionality
of,

#define
and
typedef ?

/* BEGIN new.c */

#define VOID_POINTER void *

typedef void * void_pointer;

int main(void)
{
void_pointer a, b;
VOID_POINTER c, d; /* This line won't compile */

return 0;
}

/* END new.c */

 

[Keith Thompson]

How do you feel about using typedefs to ensure consistency across
platforms, as in the case of establishing int32_t and int64_t types?
(Naturally, that requires putting your typedef definitions within
preprocessor conditionals that ascertain the nature of the
platform...)

That's a great idea -- which is why it's part of the C99 standard's
<stdint.h> header.

 

[Kenneth Brody]

Are there differences in terms of functionality
of,

#define
and
typedef ?

By the above I mean any instance when the outcome
obtained by running two versions (1) and (2) below
of C codes are different ?

For example,

(1) In one C code, it has:

#define u_ unsigned
#define uc_ unsigned char

(2) The same C code is re-writtened to:

typedef unsigned u_;
typdef unsigned char uc_;

Given your "u_" and "uc_" examples, your #define would allow:

u_ long l; /* unsigned long */

whereas the typedef wouldn't.

On the other hand, consider:

#define PCHAR char *
and
typedef char * PCHAR;

and then see what happens with:

PCHAR pt1, pt2;

There are also times when #define simply can't be used:

typedef void (*VoidVoidFuncPtr)(void);


If you want to define a type, use typedef.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Blunt Jackson]

That's a great idea -- which is why it's part of the C99 standard's
<stdint.h> header.

Cool. I haven't researched all the differences between old ansi/k&r C's
(which is what I use, mostly) and C99, but that's a nice thing to know,
and a very handy feature.

(Also, I switched off google's cruddy web interface. Correct quoting
ensues.)

-bluejack

/* Work as though you live in the younger days of a better nation */

 

[Richard Bos]

Cool. I haven't researched all the differences between old ansi/k&r C's
(which is what I use, mostly)

Note that those are two separate versions of C. First there was what is
called K&R C, which was the C that Kernighan and Ritchie described in
the _first_ edition of "The C Programming Language"; and then there was
ANSI C89, which is (more or less) what is described in K&R _2_. (And
ANSI C89 was adopted by ISO, so it's also ISO C90.)
Lastly, there was (is now) ISO C99, which was also ratified by ANSI
(being participant in ISO), so that's also ANSI C99.

The differences between K&R C and C89 are larger, IYAM, than between
both ISO Cs. For example, ANSI C89 was the one that introduced
prototypes; they weren't in K&R C.

(Also, I switched off google's cruddy web interface. Correct quoting
ensues.)

And there was much rejoicing.

Richard

 

[Keith Thompson]

Note that those are two separate versions of C.

For sufficiently large values of "two".

[description of three versions of C snipped]

 

[Richard Bos]

For sufficiently large values of "two".

No, the _old_ ANSI and K&R C are two versions. The _new_ ISO C99 is the
third, which Blunt Jackson mentioned separately.

Richard

 

[Keith Thompson]

No, the _old_ ANSI and K&R C are two versions. The _new_ ISO C99 is the
third, which Blunt Jackson mentioned separately.

Sorry, I read "those are two separate versions" as "there are two
separate versions".