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

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-08-05 17:23:07

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