Boost logo

Boost :

Subject: Re: [boost] [function] function wrapping with no exceptionsafetyguarantee
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-10-22 13:43:28


On Wed, Oct 20, 2010 at 9:41 PM, David Abrahams <dave_at_[hidden]> wrote:
> At Wed, 20 Oct 2010 18:36:01 -0400,
> Daniel Walker wrote:
>>
>> On Wed, Oct 20, 2010 at 6:04 PM, David Abrahams <dave_at_[hidden]> wrote:
>> > At Wed, 20 Oct 2010 16:51:50 -0400,
>> > Daniel Walker wrote:
>> >>
>> >> First of all, boost::function can be in an empty state for two
>> >> reasons: either it has not been assigned a target function or there
>> >> has been a problem with the internal target management system.
>> >
>> > What kind of problem?  Can you point to code that shows such a problem
>> > being detected?  Or are you merely saying, "somebody invoked UB
>> > somewhere and it nulled out the pointer?"  We don't need to support
>> > the latter.
>>
>> boost::function clones target function objects. So, there could be a
>> failure allocating and/or copy-constructing the target. When this
>> happens, vtable is set to null. You can see an example in operator= on
>> line 783 of function_template.hpp. There may be other reasons that I'm
>> not aware of which could lead to vtable being null. In principle,
>> there is nothing in the current system guaranteeing that vtable is
>> non-null at any arbitrary point in time.
>
> Of course that happens; it's not a problem.  Instead of setting the
> vtable to null it would be set to point to the empty-state function.

Right, I agree. In order to ensure that vtable is not null, everywhere
that boost::function currently sets vtable to null, instead, it needs
to set vtable to an object that can invoke an empty-state function.

Daniel Walker


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk