Subject: Re: [boost] [function] function wrapping and exception safety recap
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2010-10-19 03:34:51
"Nevin Liber" <nevin_at_[hidden]> wrote in message
> On 12 October 2010 13:28, Emil Dotchevski <emil_at_[hidden]> wrote:
>> It would have been nicer if op() didn't throw to begin with but
>> because that's how it has been, this should remain the default
> More than that, it is the behavior that is going into C++0x.
Why? To both of those arguments, why?
Should we have stuck with all the tried and tested C-style 'beauty' that we
now consider ugly and obsolete just because 'that's how it was done 'back in
While C++ is a great language, its standard library is not (a fact nicely
demonstrated at http://www.ultimatepp.org/www$uppweb$vsstd$en-us.html
http://www.ultimatepp.org/www$uppweb$vsd$en-us.html) so why should we
worship it like it is?
As if the epic failure of the standard library called iostreams somehow just
created a precedent that says that its ok to put inefficient-by-design code
into the standard library, and if you manage to get it in it will stay there
If we already know that boost::function has (relatively) inefficient
invocation and copying, is not configurable and can cause unnecessary bloat
why not fix it now even if that makes it no longer a 'perfect copy' of
std::function...? After all:
- people come/came to use Boost exactly because the standard library did not
- (for example) boost::mem_fn is not a 'perfect copy' of std::mem_fn
- the 'proper' boost::function can always be renamed to something else
(boost::functional/functionoid or something) and boost::function can be a
wrapper around the 'proper' implementation that mimics std::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
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk