Re: [boost] [function] function wrapping withnoexceptionsafetyguarantee

Subject: Re: [boost] [function] function wrapping withnoexceptionsafetyguarantee
From: Emil Dotchevski (emil_at_[hidden])
Date: 2010-10-23 21:48:40

On Sat, Oct 23, 2010 at 2:30 PM, Domagoj Saric <dsaritz_at_[hidden]> wrote:
>
> "Emil Dotchevski" <emil_at_[hidden]> wrote in message
> news:AANLkTik0aePsrXAPPUt8-MnbTT7863bB8_51x+8YfWaL_at_mail.gmail.com...
>>
>> As pointed out, the check can be removed. We're waiting for someone
>> who cares about the current inefficiency of the check to remove it
>> instead of arguing. :)
>
> I am sorry but I'm really starting to doubt someone's sanity here....
> You keep saying things to the effect of the above statement while I keep
> replying to you that I care and already have (as well as others), long ago,
> 'removed the check' as well as made many other improvements (along with
> links to code, tests and discussions)....which you again ignore....and so we
> go....'running in circles'....ad nauseam...
> Am I the only one seeing my own particular posts on this subject on this
> list?

The check and the associated overhead can be easily removed in
boost::function. I have not seen anyone post a diff that removes the
check in boost::function. Maybe I missed it.

>>> - there is no way to choose a different on-empty behaviour
>>
>> You're missing the point I believe Edward is making. Throwing an
>> exception when an empty function is called is a valid behavior in case
>> the on-empty behavior is undefined (don't call empty functions if you
>> don't want the exception.)
>
> - never asked for the removal/configurability of the hardcoded
> throw-on-empty policy with the explicit goal to specifically get
> undefined-behaviour instead (this would obviously be oxymoronic) >but< to
> remove it to get rid of the associated >overhead< and >runtime dependencies<

The link dependency (in BOOST_NO_EXCEPTIONS builds) on
boost::throw_exception exists specifically to enable using Boost when
exceptions are disabled. If that system is flawed, let's talk about
improving it (note that its semantics are a perfect match for the
requested empty-function-call semantics.)

That said, anyone can implement a new policy-based function library,
specify its interface (write documentation) and request a Boost
review.

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