[boost] Re: sans-Re: PlatformNeutrality-withoutreinterpret_cast<>andifdef

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-08-05 18:08:53

From: "David Bergman" <davidb_at_[hidden]>

> 2. Is #ifdef really a "non-standard compiler extension" as you claim?
> There are ugly things that are still standard, one of those is actually
> the macro layer imposed by #ifdefs.

Yes, and with that macro layer (and the other preprocessor facilities) we can do
things that just aren't possible with the core language alone, yet still remain
compliant with the standard.

> We all have moments when we tend to lose our beliefs in software
> standardization, and maybe in the whole software industry, but those
> moments should not coincide with moments of frenetic posting.

Yes.  It is a balance between stability and extension that nobody ever agrees on
exactly.

> From: Eric Woodruff

> It is clear the the #1 principle is violated:
> "Aim first for clarity and correctness; optimization should be only a
> secondary concern in most Boost libraries."

You have to keep in mind as well that, as a library, Boost cannot always assume
that it will not be in an environment where optimization is necessary.

> #ifdef's are certainly not very clear, and definately not correct. Use
> of
> the preprocessor mutates the language, violating the standard, and thus,
> should only be used to assist a defficient compiler.

Use of the preprocessor mutates the _text_, not the language, doesn't violate
the standard, and gives us tools to use in areas where the core language is
deficient.

> In that case, principle #2 is also ignored:
> "Aim for ISO Standard C++. Than means making effective use of the
> standard
> features of the language, and avoiding non-standard compiler extensions.
> It
> also means using the C++ Standard Library where applicable. "
>
> But this is the accepted way of the majority.

It is not only just accepted; the preprocessor is not a non-standard compiler
extension--it is a required part of the translation of every C/C++ program.
Examples of compiler extensions would include use of variadic macros in C++ or
using the typical 'charizing' operator.  I seriously doubt that there is
anywhere in Boost that uses the 'charizing' operator extension.  Any use of
variadic macros, on the other hand should be protected from C++ and C (pre-C99).

Paul Mensonides