[boost] Re: future of boost.threads

From: David Abrahams (dave_at_[hidden])
Date: 2004-02-10 12:01:13

"Brock Peabody" <brock.peabody_at_[hidden]> writes:

>> -----Original Message-----
>> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
>> On Behalf Of David Abrahams
>
>> There are better ways.  Boost.Python uses a dynamic registration
>> technique.  
>
> Do you think that this technique could be factored out to solve the problem
> with threads?  

Sure; it would be easy.

> Another problem I've had to deal with is propagating
> exceptions through windows message handlers.

I'm not sure what the issues there are.

>> Compile-time enumeration of the exceptions is overkill and not
>> sufficiently flexible.
>
> If anything I'd say compile-time enumerations is underkill.  Typically I'd
> only be interested in one or two types of exceptions and something like
> this:
>
>    run_and_throw<my_lib::socket_error, std::exception>(f);
>
> Or maybe something like lambda::try_catch seems much simpler than anything
> involving dynamic registration.  On the other hand, I agree that it's not as
> flexible.  Are you referring to the problem with splicing in
> particular?

Splicing?

No, I'm referring to the great deal of compile-time machinery needed
to generate a structure which can ultimately be done nearly as
efficiently at runtime.

Generally if you have a bunch of interacting libraries it makes sense
for each one to be able to register its exception
serializers/deserializers/translators or whatever.  Why should the
thread invoker have to enumerate the possibilities each time?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com