3 ms·
I think the advice here is a bit extreme. Let me focus on macros for the moment. As an initial and trivial matter, using macros and defining new macros are dif
by torstenvl 7y ago
I think the advice here is a bit extreme. Let me focus on macros for the moment.
As an initial and trivial matter, using macros and defining new macros are different things. It's absurd to say you can't use macros, and comparison to ((void *)0) rather than to NULL is far less readable. Using macros defined by the language is incontrovertibly normal, expected, and the Right Thing.
As far as defining new macros, though, I still think there are very defensible reasons to use them, especially for defining a macro that expands to debug code when a debug constant is defined, and expands to nothing when that same debug constant is undefined.
#ifdef _MY_DEBUG
#define ENTER 1
#define EXIT 2
#define TRACE(x) \
fprintf(stderr, "%s function %s\n", (x == ENTER) ? "Entering" : "Exiting", __func__)
#else
#define TRACE(x)
#endif
Forgive any errors above, but that's pretty straightforward to follow and can make debugging a lot easier by giving a naive sort of stack trace on stderr. Add TRACE(ENTER) and TRACE(EXIT) at the beginning and end of functions and you can figure out where a segfault or whatever is happening, and it all gets defined away in non-debug code.