On Tue, Oct 19, 2010 at 12:32 AM, Domagoj Saric <dsaritz@gmail.com> wrote:
"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...
Even if there were sufficient demand to change boost::function, that's not how Boost works. Each Boost library has a maintainer and once the library is accepted, (s)he needs to be sold on the change. There's also the issue that it seems a good idea to keep boost::function unchanged so it doesn't deviate from std::function. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode