Re: [boost] [function] function wrapping withnoexceptionsafetyguarantee

Subject: Re: [boost] [function] function wrapping withnoexceptionsafetyguarantee
From: Edward Diener (eldiener_at_[hidden])
Date: 2010-10-23 23:17:56

On 10/23/2010 5:30 PM, Domagoj Saric 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?
>
>
>>> - 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.)
>
> More of the straw man arguments...it is quite obvious that just about
> anyone complaining about the on-empty behaviour of boost::function simply:
> - does not care about the 'academic' meaning of 'undefined behaviour'
> - does not care about the 'academic' meaning of 'behaviour' per se but
> about behaviour in the context of the overhead and dependency
> implications/requirements of that particular behaviour
> - 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< (simply unavailable in some environments), in turn
>  >accepting< to get undefined behaviour >through/because of a call
> through a null function pointer< if they fail to obey by their promise
> not call an empty boost::function...
>
> IOW, the fact that in theory, while not in practice, 'undefined
> behaviour' may mean 'anything', thus also the same throw-on-empty
> behaviour that we have in status quo, has exactly zero relevance to the
> core point in question because, >even in theory<, 'undefined behaviour'
> does not imply any sort of implementation or 'physical code' or
> 'overhead' or 'dependency' and >that< is the core point in question,
> making your 'academic' argument (that again, I'm sorry, you seem to be
> repeating ad nauseam) a text book example of a straw man argument...
> (Because the status quo implementation does have unwanted overheads and
> dependencies while the proposed ones do not/offer some improvement, and,
> again, the fact that you repeatedly try to prove that theory says that
> there is no difference, and hence gives no justification for the claim,
> is fully irrelevant because you sidestep and distort the original claims
> and requests in order to get to your point...the only remaining question
> is why?)
>
>
> ps. Edward was asking "why others are upset that invoking
> boost::function on an empty target should throw an exception", whether
> or not this implies he meant specifically and solely on the issue of
> behaviour (separated from the context of overhead and dependencies),
> which is the issue of the above described straw man argument, is
> irrelevant...because even if he did it would be 'valid' of me then to
> point him to the real merit and context of the discussion....

I meant simply what I said. Please explain to me why boost::function 
throwing an exception when invoked on an empty target is objectionable 
to you. If I have misunderstand to what you are objecting I apologize, 
but it seems to me that you find this behavior incorrect somehow.

In reading the documentation it clearly states:

"boost::bad_function_call — An exception type thrown when an instance of 
a function object is empty when invoked."