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? 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?
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
>
