"Peter Dimov" <pdimov@pdimov.com> wrote in message news:C08645771EF04EAEBD9230358B35BDFB@pdimov5...
David Abrahams wrote:
Is *that* the core issue here? Because it seems like the issue has been about various other things earlier in this conversation.
The core issue, if I remember correctly, is that when a library uses boost::function internally without ever calling it while NULL and the user compiles with exceptions disabled, he needs to supply a definition of boost::throw_exception even though it will never be called.
IMO, if we try to look at this discussion in the context of all the other boost::function related discussions and all the various alternative implementations that circulate around the internet, the core issues jump right out: it is always about inefficiency and/or lack of configurability... Considering that those issues are consistently brought up every once in a while, the question that logically follows is why do we still have the boost::function implementation that we do? After all, a fraction of the effort spend in these run-around-in-circles discussions would have been enough to make relevant changes to boost::function... -- "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