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

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-06 09:36:23

----- Original Message -----
From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, August 06, 2002 4:08 AM
Subject: Re: [boost] Re: Re: Re: Platform
Neutrality-withoutreinterpret_cast<>andifdef

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

You shouldn't have.  Semaphores weren't relegated to absolute non-inclusion.
They were removed as being dangerous enough to warrant serious research and
design before consideration of actual inclusion.

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

Depends on what you mean by "pass".  Asynchronous exceptions are so unsafe
that they are basically not usable.  A polling form of exception passing is
usable for select cases.  For instance, that's precisely how thread
cancellation will be implemented.  The boost::threads design does not
exclude the ability to do this today.   I'm leaning towards leaving this
subject at that because:

1) It's difficult to use this in a manner that's safe and correct and will
be abused and misused frequently if it's added to the provided interface.

2) It's rarely useful.

3) Implementing it yourself is trivial, and can often be optimized for your
specific needs.

> axiom1: there is no such thing as "absolute safety".

Of course not.

> axiom2: attempting to reach "absolute safety" is like searching for the
> "end of the rainbow"

Not really.  Searching for the end of the rainbow is simply wasted effort.
Reaching for "absolute safety", on the other hand, can help a design to
actually be safer, even though "absolute safety" can never be reached.

> axiom3: doing the same thing repeatedly and expecting different results
> (e.g. "we have achieved absolute safety")  is insanity.

Huh?

> axiom4: many things are inherently dangerous

Yes, but one should take as many precautions against such things as is
reasonable to do.  I think there's been only one case in the design where I
can actually be accused of possibly standing in someone's way in the name of
safety... and that's with not exposing lock/unlock on the mutex types.  That
decision is *still* under consideration, however.

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

Sorry, I honestly don't feel I've done this.

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

Because from experience this particular area of computing is one that
produces the largest amount of bugs, and the bugs are extremely difficult to
detect during testing, and to diagnose and correct once detected (usually in
production).  The need to consider safety is a little higher here then in
other areas, even though you're still left with plenty of rope to shoot
yourself in the foot with.

> 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

I appreciate your concern and opinion, and if you think I am putting safety
above all other considerations then by all means continue to fight the
fight.  Safety wasn't the lone consideration for rejection of the exception
passing mechanism, though, so you'll have to argue the other points as well
to convince me.

Bill Kempf