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
>> 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
>>> - 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."
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk