Boost logo

Boost :

Subject: Re: [boost] [function] function wrapping with no exception safetyguarantee
From: Emil Dotchevski (emil_at_[hidden])
Date: 2010-10-19 03:56:55


On Tue, Oct 19, 2010 at 12:32 AM, Domagoj Saric <dsaritz_at_[hidden]> wrote:
>
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> news:C08645771EF04EAEBD9230358B35BDFB_at_pdimov5...
>>
>> David Abrahams wrote:
>>
>>> Is *that* the core issue here?  Because it seems like the issue has
>>> been about various other things earlier in this conversation.
>>
>> The core issue, if I remember correctly, is that when a library uses
>> boost::function internally without ever calling it while NULL and the user
>> compiles with exceptions disabled, he needs to supply a definition of
>> boost::throw_exception even though it will never be called.
>
> IMO, if we try to look at this discussion in the context of all the other
> boost::function related discussions and all the various alternative
> implementations that circulate around the internet, the core issues jump
> right out: it is always about inefficiency and/or lack of configurability...
> Considering that those issues are consistently brought up every once in a
> while, the question that logically follows is why do we still have the
> boost::function implementation that we do? After all, a fraction of the
> effort spend in these run-around-in-circles discussions would have been
> enough to make relevant changes to boost::function...

Even if there were sufficient demand to change boost::function, that's
not how Boost works. Each Boost library has a maintainer and once the
library is accepted, (s)he needs to be sold on the change.

There's also the issue that it seems a good idea to keep
boost::function unchanged so it doesn't deviate from std::function.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk