Eric Lemings wrote:
Another related question, not so much style-based though.
Why the parentheses around preprocessing symbols in an `#if defined
(FOO)`
directive but not in an `#ifdef FOO` directive?
The parentheses are only allowed in the defined operator, not in
the #ifdef/#ifndef directives.
Example:
$ grep -n "^#if" $SVNROOT/trunk/src/exception.cpp
...
src/exception.cpp:303:#ifdef _RWSTD_NO_EXCEPTION_COPY_CTOR
src/exception.cpp:307:#if defined (__INTEL_COMPILER)
...
For that matter, why use parentheses in a if-def at all?
I can't think of a reason. Feel free not to use them. I might even
join you myself.
Martin
Brad.
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Wednesday, April 16, 2008 1:37 PM
To: [email protected]
Subject: Re: Another style question
Eric Lemings wrote:
[...]
Btw., a more flexible way to code these workarounds would have been
to code it like so:
#if !_RWSTD_NO_MEMBER_TEMPLATES
// correct code
#else
// workaround
#endif
This way, each config macro could be #defined on the command line
to 0 or 1 to toggle either branch (e.g., for testing and
debugging).
That's not possible with the #ifndef approach.
From a natural language perspective, I've always found the double
negatives (e.g. `#ifndef _RWSTD_NO_FOO) a bit irritating but that's
just me.
I don't like it either but I think it has two important advantages
over the alternative (e.g., the GNU HAVE_FOO style). First, in a 100%
conforming environment our convention makes it, at least in theory,
possible to compile the library without having to configure it,
while the other always requires the config tests, or will produce
a badly crippled library when none of the config macros is defined.
Second, our approach will end up with fewer #defined macros than
the other strategy.
Martin
