Naming
Guy Helmer
ghelmer at dsuvax.uucp
Fri Mar 2 03:19:00 AEST 1990
In article <MCDANIEL.90Feb28130347 at amara.amara.uucp>, mcdaniel at amara.uucp (Tim McDaniel) writes:
> gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
> You may #define your own malloc macro only if you don't #include <stdlib.h>.
> ...
> It would be better to use some name other than malloc for this macro.
Yes. Anyone other than the author might have a great time ( :-) ) deciphering
code written this way.
> Suppose I just want to put a wrapper around a system function. [...]
>
> In such a case, I would like to just do
> extern void * my_malloc(size_t);
> #undef malloc
> #define malloc(x) my_malloc(x)
> where my_malloc does wrapperish stuff and then calls the real malloc
> to do the real work. I'd set up "my_stdlib.h" with such declarations.
The original purpose for this idea seemed to be to use the preprocessor
to put in calls to debugging code; if this is the case, why not write
something like:
#ifdef DEBUG_ON
#define MALLOC(x) my_malloc((x), __FILE__, __LINE__)
#else
#define MALLOC(x) malloc(x)
#endif
If I were to read code written this way, I think I would understand
a thousand times faster what the author's intent was. This also
avoids all the trouble with library routines defined as macros,
doesn't it?
> Tim McDaniel
> Applied Dynamics International, Ann Arbor, MI
> Internet: mcdaniel%amara.uucp at mailgw.cc.umich.edu
> UUCP: {uunet,sharkey}!amara!mcdaniel
--
Guy Helmer ...!uunet!loft386!dsuvax!ghelmer
Dakota State University Computing Services helmer at sdnet.bitnet
Software Engineering: "'How to program if you cannot.'" - Dijkstra
More information about the Comp.std.c
mailing list