On 10/22/2010 1:35 PM, Daniel Walker wrote:
On Thu, Oct 21, 2010 at 7:05 PM, Daniel Walker <daniel.j.walker@gmail.com> wrote:
On Thu, Oct 21, 2010 at 6:13 PM, Edward Diener<eldiener@tropicsoft.com> wrote:
On 10/21/2010 6:05 PM, Daniel Walker wrote:
Right. I don't mean the management system has a bug, I mean that it has encountered a problem, for example, cloning the target. So, boost::function could be empty because it has never been assigned a target or because the most recent attempt to assign a target failed... or because it was cleared by the user calling clear(). Are those all of the scenarios that can lead to an empty boost::function?
I don't mean to question the design of boost::function but wouldn't the inability of cloning a target, or assign a target, be a problem which should lead to an exception being thrown ?
Right, but suppose boost::function was instantiated outside of the try block where the assignment fails. Then after the exception is thrown and handled, the boost::function object could still be used.
But actually, I just noticed that, even though the portable function wrappers are empty after an assignment failure, boost::function is not actually cleared. So, in fact, a failed assignment is NOT a scenario that leads to an empty state, as I first thought. This is probably an oversight/bug in the portable wrappers, right?
I would assume that boost::function not having a target would normally only occur if no target had been set or if the user removed a target which had been set.
Right, and indeed, this appears to be the case... unless there's some other scenario we overlooked...
Oops. Sorry, I spoke too soon. In fact, it IS currently possible for a boost::function object to become empty due to a failed assignment. It happens because the small object manager clones the target during a call to swap(). If there is an exception during the allocation, boost::function handles it, sets itself to empty and rethrows.
That's understandable. Once an exception is thrown its the end-user's responsibility to deal with the end result. I do not understand why others are upset that invoking boost::function on an empty target should throw an exception. It is equivalent in my mind to calling a function through a function pointer which is null.