Re: Operational and functional differences - #define vs typedef ?

O Plameras <oscarp@xxxxxxxxxxx> 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) kst-u@xxxxxxx <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.
.

Relevant Pages

  • Re: Is there a convention mandating macros to be all-uppper-case?
    ... typedef std::wstring tstring; ... to keep namespaces intact. ... Macros are even worse, because they make the substitution completely blindly, without any consideration to their real meaning. ... At least with typedef, you can be sure it's not going to disrupt types in other namespaces, member functions in other classes, etc. ...
    (microsoft.public.vc.language)
  • Re: Why we should (not?) have closures after all
    ... A typedef facility will allow programmers to use ... expressiveness, further decreasing maintenance costs. ... C macros are particularly limited, but a real macro facility is ... how to prevent programmers from doing bad things. ...
    (comp.lang.java.programmer)
  • Re: Use a suffix or a type cast?
    ... I have heard that a suffix is not a good solution and type casts are ... We already had a typedef: ... But much easier than faffing with macros to try and achieve that was: ...
    (comp.lang.c)
  • Alternatives for redefining a typedef?
    ... The PROPERTY macros ... A typedef inside BEGIN_CLASS is almost good, ... BEGIN_CLASS would redefine ThisClass, causing a compile error. ... functions, and be redefined later, and also be used as a template ...
    (comp.lang.cpp)
  • Re: A function that returns a pointer on a function
    ... and which is the syntax? ... Trying to do that without using a typedef is a real test of your ... understanding of type declarations. ... It is however impossible to define a function that returns a pointer to ...
    (comp.lang.cpp)
Loading