Subject: Re: [boost] [function] function wrappingwithnoexceptionsafetyguarantee
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-11-07 15:41:08
On Sat, Nov 6, 2010 at 7:53 PM, Peter Dimov <pdimov_at_[hidden]> wrote:
> Daniel Walker wrote:
> On Sat, Nov 6, 2010 at 2:08 PM, Emil Dotchevski <emil_at_[hidden]>
>>> Can someone please explain why does storing the empty state take space
>>> per type?
>> Storing a target function takes space per type, namely, the static
>> stored_vtable on line 912 of boost/function/function_template.hpp, which is
>> dependent on both the type of boost::funciton's signature and the type of
>> the target function.
> It doesn't have to.
> void throw_bad_function_call()
> throw bad_function_call();
> function<void()> f( &throw_bad_function_call );
> doesn't take up any additional space per type, unless of course the program
> never stores a function pointer into function<>.
This is a special case: all targets are function pointers of the same
type, right? However, this defeats the purpose of boost::function. If
all targets are the same type, the user doesn't need to use
boost::function in the first place! This is not a motivating use case.
The user would be better off using the target type directly or making
the type a template parameter as the std algorithms do.
boost::function is a polymorphic function wrapper; it is used to store
callable objects of different types and that's the problem domain we
should focus on. It's interesting to think about and thanks for
bringing it up, but I don't believe it is worthwhile to optimize
boost::function for use cases that are tangential to its problem
> It doesn't take up any additional space in the code segment either,
On my system, the text segment grows by up to 14% when
boost::function( &throw_bad_function_call ) is used for empty
wrappers. The reason is because of the extra template instantiations
needed to support the type of throw_bad_function_call, which may not
be the same as the type of any other target.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk