Re: [boost] Re: Re: Threads & Exceptions

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-13 10:02:10

----- Original Message -----
From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>
> At Monday 2002/08/12 11:48, you wrote:
> >Uhmmm... you recall incorrectly then.  I would never have done that, as
it's
> >illegal.  The example I posted didn't do this.
>
> you are, of course, correct
> In my haste, I didn't recognize your use of the name main (in function
> main) where it should be _obvious_ (sarcasm intended) that it couldn't
> possibly be mistaken for the address of a function.

Ahh... I understand where the confusion lies now, and I do deserve some
admonishment.  I used the name main because, in haste, it seemed to convey
the purpose, but you're quite right that it only causes confusion with
main().  Sorry about that.

> I'm not sure that language support is all that's needed.  Tho I really
wish
> _some_ HLL would get around to having a swap operator (declaring it
needing
> to be atomic would be ++good) it might even be sufficient.

I don't follow your thinking here, but I get the feeling you don't
comprehend the issue.

> as an aside, I _detest_ coding to the "lowest common denominator" which we
> appear to "have" to do.

It's not a "lowest common denominator" issue.  The problem at hand here is
undefined by ALL the APIs, as well as the C++ standard.

> >If you can define what's erroneous, let alone how it's erroneous, then
the
> >accusation is baseless.  Believing I'm wrong is not the same thing as
> >proving I'm wrong.
>
> no kidding.... OJ isn't in jail.

You're being a little adversarial again.  Work with me, not against me.

> >   You could reword what you just said as an opinion, and I
> >wouldn't object (though I'd still ask you to do the leg work to prove me
> >wrong), but as it is you're not stating opinions but accusing me of
> >something you can't prove.  That's a baseless accusation.
>
> Ok, it is my opinion that there is nothing in the standard (that has been
> presented thus far) that would preclude implementing the separation of
call
> and return to/from a function via a thread mechanism, and that furthermore
> exceptions _could_ be passed back when the return from the function was
> instantiated.

And this is what I think clinches that you don't understand the issue at
hand.  I never claimed there was anything that precluded the separation of
call and return to/from a function via a thread mechanism.  Or that
exceptions could be passed back when the return from the function was
instantiated.  I claimed that the concept could not be applied _to the main
thread_, because that results in an explicit call to terminate(), possibly
with out stack unwinding, no less.

Bill Kempf