Boost logo

Boost :

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
> 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' 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 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

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 

Boost list run by bdawes at, gregod at, cpdaniel at, john at