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

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

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
> From: "William E. Kempf" <williamkempf_at_[hidden]>
> > From: "Peter Dimov" <pdimov_at_[hidden]>
> > >
> > > The more I think of it, the more I like the thread<void> special case.
> It
> > is
> > > logical: when you ask for a thread that returns a value, this implies
> that
> > > you will join() that thread. When you use thread<void>, you don't care
> > about
> > > the return value.
> >
> > It's not logical (to me at least).  Functions that return void can still
> > throw exceptions.  More over, you'll often still want to join() a
> > thread<void>.  A so no correlation to nothrow semantics and void
returns,
> > even when talking about a thread call.
>
> Using thread<void> means that I am not interested in the return value, not
> that the thread function returns void (it is not required to do so) or
that
> I'll never call join. Therefore, (my logic goes) by extension I am not
> interested in "exceptional" returns, too.

I undertand that the actual function called might still return something,
but that adds to my argument ;).  I also understand the logic you're
applying, but the logic doesn't fit the bigger picture to me.

> It might be a stretch.

I think so.  Which is only evidence that the logic applied isn't necessarily
the logic that everyone would apply, and thus the premise (that thread<void>
would indicate nothrow semantics) is shaky at best.

Bill Kempf