"Emil Dotchevski" <emil@revergestudios.com> wrote in message news:AANLkTik0aePsrXAPPUt8-MnbTT7863bB8_51x+8YfWaL@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