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

From: David Brownstein (David_at_[hidden])
Date: 2002-08-05 18:52:34

When you said:
>the communities own design philosophies are brutally ignored
> by its own members.
this implied a historical perspective, because a claim like this could only
substantiated by reviewing the history of the boost community. When you
respond by later saying:

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

then I think that you have admitted that your statement "the communities own
design philosophies are brutally ignored
by its own members" cannot be substantiated by you.

Anyway, I agree with you that generally #ifdef's make code difficult to read
and should be avoided when possible. If you had been following the community
discussion, you would know that many of the existing #ifdef's are used to
"assist... deficient compiler(s)". The development list is not only a good
tool for discussion, it is also a historical body of commentary, AND an
excellent place to learn about advanced C++ practice. I hope that you will
use it carefully and considerately, and participate in this shared venture.

Respectfully,
David

----- Original Message -----
From: "Eric Woodruff" <Eric.Woodruff_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, August 05, 2002 3: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."
>
> #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.
>
> 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.
>
> ----- Original Message -----
> From: David Brownstein
> Newsgroups: gmane.comp.lib.boost.devel
> Sent: Monday, 2002:August:05 5:59 PM
> Subject: Re: Re: Re: Re:
> PlatformNeutrality-withoutreinterpret_cast<>andifdef
>
>
> Eric,
> Please explain which of the communities design principles you believe have
> been "brutally" ignored? I assume that you have followed the design and
> implementation of boost::threads since the beginning (with all the
attendant
> discusions), and are hence prepared to provide a detailed analysis that
will
> back up this claim?
>
> David
> ----- Original Message -----
> From: Eric Woodruff
> To: boost_at_[hidden]
> Sent: Monday, August 05, 2002 2:09 PM
> Subject: [boost] Re: Re: Re: Platform
> Neutrality-withoutreinterpret_cast<>andifdef
>
>
> Please explain how boost users are supposed to maintain a level of
> confidence in the safety of this foundation that is aimed at addressing
the
> impotence of C++ itself, by providing things that were left out of the
> standard, when the communities own design philosophies are brutally
ignored
> by its own members.
>
> Boost doesn't stand to make any profit, so then why doesn't it stand on
it's
> principles above the alternatives? It seems that upon examination, boost
is
> going the way of all other open projects that exist. This is leading me to
> believe that inspecting of OpenSceneGraph, which also provides an image of
> holding high-standards, will prove the same.
> ----- Original Message -----
> From: William E. Kempf
> Newsgroups: gmane.comp.lib.boost.devel
> Sent: Monday, 2002:August:05 4:40 PM
> Subject: Re: Re: Re: Platform
Neutrality -withoutreinterpret_cast<>andifdef
>
>
> ----- Original Message -----
> From: "Eric Woodruff" <Eric.Woodruff_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Monday, August 05, 2002 3:07 PM
> Subject: [boost] Re: Re: Platform Neutrality -
> withoutreinterpret_cast<>andifdef
>
>
> > I can understand the hit taken in the readability of the mutex
> > implementation for "efficiency," but it is unacceptable for thread. I've
> > read boost's biases and the thread implementation is a certain violation
> of
> > the heart of boost's principles.
>
> Eric, I think you're getting confrontational.  Boost went through formal
> review and no one had the objections to the *implementation* that you do.
> More over, Boost.Threads is hardly the only Boost library that uses
> conditional compilation in this manner.  If you're going to accuse me of
> violating the heart of Boost's principles you'd better back it up with
> citations.
>
> Truth be told, a pre-review version of the library used the PIMPL idiom
for
> the reasons you cited, and it received numerous complaints for having done
> so.  The current usage of conditional compilation is a result of the Boost
> membership requesting this.
>
> Bill Kempf
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost