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

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-05 17:56:35

----- Original Message -----
From: "Eric Woodruff" <Eric.Woodruff_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, August 05, 2002 5:23 PM
Subject: [boost] Re: Re: Re:
Re:PlatformNeutrality-withoutreinterpret_cast<>andifdef

> Historical facts are not very relevant to the current state. I never made
> any claim to have been following the development list prior to, well,
> yesterday.
>
> 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."

Now we have an idea of what you think was violated.  Let me proceed on that
basis...

> #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.

Let's leave aside clarity for a second.  We'll come back to that argument
later.

Using #ifdef's is certainly not "not correct" (to use a double negative).
Conditional compilation is a part of C++, and usage of it does not "violate
the standard".  The only possible way it could "violate the standard" would
be if it resulted in a violation of the one definition rule, but the usage
of conditional compilation in Boost.Threads does not result in this.  On
this argument you have no facts to hold up your side.

Now, back to clarity.  Clarity is in the eye of the beholder.  Many people
would find the use of PIMPL to be as unclear as, or more so, then the use of
conditional compilation.  In this very specific case, the membership spoke
out, and they do not find conditional compilation to detract from the
clarity, and in fact preferred its usage over the PIMPL idiom.  You're
within your rights to disagree here, but that disagreement does not mean
that anything has been violated, nor does it have much weight against the
voice of the rest of the group.  I have sympathy for you, but that's about
all.

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

Sorry, no, this isn't violated either.  The library has aimed for ISO
Standard C++ conformance.  The only areas in which it doesn't do this are in
areas where a) it's impossible since we're dealing with a concept that's
outside of current C++ standards and b) the goal is to define these concepts
in a way that's compatible with the C++ standard and can be added to the
next revision.  If you read the actual quote again, it specifically and
purposefully allows this sort of non-standard code.

Bill Kempf