Re: [boost] Re: Re: Re: Platform Neutrality-withoutreinterpret_cast<>andifdef

From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2002-08-06 04:08:53

Geez, I hate to have to chime in on Eric's side (since I disagree with some 
of what he says), but it _should_ be the "stated" or "posted" will of the 
community.  I found the arguments ("they're not safe") for deleting 
semaphore so specious that I gave up on attempting any further criticism.

Ben Franklin said (in respect to human interaction)"They that can give up 
essential liberty to obtain a little temporary safety deserve neither 
liberty nor safety."
I believe the same applies here.  Refusing to implement some method of 
being able to pass an exception (ok, maybe not ALL exceptions, I personally 
find the concept of "throw 7;" to be an abomination of the body of C++) 
across thread boundaries because it's not "safe' disappointing.

axiom1: there is no such thing as "absolute safety".
axiom2: attempting to reach "absolute safety" is like searching for the 
"end of the rainbow"
axiom3: doing the same thing repeatedly and expecting different results 
(e.g. "we have achieved absolute safety")  is insanity.
axiom4: many things are inherently dangerous

I'm suggesting that we quit using "it might not be safe if misused" as a 
mantra.  It's a consideration, that's all.  "Gee, this might be unsafe if I 
misuse it...I'd better be careful."

We're not children here.  We handle dangerous things every day (knives, 
driving, etc).
The language cannot protect against a lot of things that will cause the 
program to blow up, why are we so worried about this one?

as the guy in the next office said...waaaay back when:  "If you make a 
system that even a fool can use, only a fool will use it."  Dennis J. Maine

At Monday 2002/08/05 14:50, you wrote:
>Final warning, Eric: tone down the rhetoric or we will ban you from the
>list.
>
>If any design philosophies are being ignored here (which I seriously
>doubt), it's certainly not "brutal".
>I'd say if anything you're ignoring what Bill said about the fact that the
>current implementation is based on the will of the community.
>
>-Dave (still trying to be on vacation and getting seriously annoyed)
>
>-----------------------------------------------------------
>            David Abrahams * Boost Consulting
>dave_at_[hidden] * http://www.boost-consulting.com
>
>
>----- Original Message -----
>From: "Eric Woodruff" <Eric.Woodruff_at_[hidden]>
>To: <boost_at_[hidden]>
>Sent: Monday, August 05, 2002 5: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

Victor A. Wagner Jr.      http://rudbek.com
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
               "There oughta be a law"