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

From: David Bergman (davidb_at_[hidden])
Date: 2002-08-05 17:47:26

Eric,

I belong to that "self-promoting profession" of yours, but am a bit
curious about what you mean by some of your claims here.

1. What do you mean by an #ifdef not being correct? We can all agree
that it is not what one would first use, if there are alternatives, but
"correct"? Correct with respect to what semantics?

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.

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.

/David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Eric Woodruff
Sent: Monday, August 05, 2002 6:23 PM
To: boost_at_[hidden]
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