By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,382 Members | 1,567 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,382 IT Pros & Developers. It's quick & easy.

Operational and functional differences - #define vs typedef ?

P: n/a
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

Dec 15 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
O Plameras <os****@acay.com.au> writes:
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.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Dec 15 '05 #2

P: n/a

Keith Thompson wrote:
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

Dec 15 '05 #3

P: n/a
O Plameras wrote:

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 */

--
pete
Dec 15 '05 #4

P: n/a
"bluejack" <bl******@gmail.com> writes:
Keith Thompson wrote:
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...)


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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Dec 15 '05 #5

P: n/a
O Plameras wrote:

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:Th*************@gmail.com>

Dec 16 '05 #6

P: n/a
On Thu, 15 Dec 2005 15:30:12 -0800, Keith Thompson <ks***@mib.org> wrote:
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 */
Dec 16 '05 #7

P: n/a
"Blunt Jackson" <bl******@no.diatom.spam.com> wrote:
On Thu, 15 Dec 2005 15:30:12 -0800, Keith Thompson <ks***@mib.org> wrote:
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)


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
Dec 16 '05 #8

P: n/a
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
"Blunt Jackson" <bl******@no.diatom.spam.com> wrote:
On Thu, 15 Dec 2005 15:30:12 -0800, Keith Thompson <ks***@mib.org> wrote:
> 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)


Note that those are two separate versions of C.


For sufficiently large values of "two".

[description of three versions of C snipped]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Dec 16 '05 #9

P: n/a
Keith Thompson <ks***@mib.org> wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
"Blunt Jackson" <bl******@no.diatom.spam.com> wrote:
On Thu, 15 Dec 2005 15:30:12 -0800, Keith Thompson <ks***@mib.org> wrote:

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


Note that those are two separate versions of C.


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
Dec 19 '05 #10

P: n/a
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Keith Thompson <ks***@mib.org> wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
> "Blunt Jackson" <bl******@no.diatom.spam.com> wrote:
>> On Thu, 15 Dec 2005 15:30:12 -0800, Keith Thompson <ks***@mib.org> wrote:
>> > 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)
>
> Note that those are two separate versions of C.


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.


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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Dec 19 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.