Boost logo

Boost :

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?


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

Boost list run by bdawes at, gregod at, cpdaniel at, john at