> > 1. Demonstrate how to write a simple max() preprocessor macro that
> > takes two arguments and evaluates to the one that is greater,
> > using normal < comparison. What are the usual pitfalls in
> > writing such a macro?
> One pitfall is to enclose all variables in parenthesis because
> otherwise the operation priority might get messed up, as when a
> [macro argument] itself contains a '<'.
> There are probably other pitfalls.
The main problem with macros is name collision, in this case with
the std::max function from <algorithm> (I think). And guess what?
The Microsoft compiler (I won't mention its evil name) is shipped
with a standard library that *does not* define std::max, because
there's a max macro in <windows.h>... ;-)
Another pitfall, but in using, not writing, a macro, see below.
> > 2. What can a preprocessor macro not create? Why not?
> Type safety.
Use of macros is type-safe, since the expanded code is checked by
the compiler -- but macros can't *create* type safety, so this is
Quote:> Evaluation safety. Consider max(++x,y).
I'd put that in the pitfalls category? (See above.)
I'd add to this list, in my opinion at the top: a macro cannot
create another macro or preprocessor directive. Probably because
of efficiency and language complexity considerations, but this is
an engineering decision. There are ways to do Bad Things if
macros can create macros, but then Bad Things can always be done
in any general programming language.
Some of the things that could be accomplished with a "dynamic"
macro language can be accomplished by template classes.
The main thing I miss is to be able to define a module "USING"
macro (I don't use "#pragma once" since for portability include
guards must be defined anyway).
alf_DOT_steinbach_AT_ac_DOT_com (clean the address before replying)
After 1. january 2000: alf_DOT_steinbach_AT_mogul_DOT_com
Sent via Deja.com
[ about comp.lang.c++.moderated. First time posters: do this! ]