Re: [boost] [function] function wrapping withnoexceptionsafetyguarantee

Subject: Re: [boost] [function] function wrapping withnoexceptionsafetyguarantee
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2010-10-23 17:30:27

"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....

-- 
"What Huxley teaches is that in the age of advanced technology, spiritual
devastation is more likely to come from an enemy with a smiling face than
from one whose countenance exudes suspicion and hate."
Neil Postman