|
Boost : |
From: Eric Friedman (ebf_at_[hidden])
Date: 2003-10-03 21:22:01
As I have previously established, a failure recovery technique is needed in
general for variant assignment (see
http://aspn.activestate.com/ASPN/Mail/Message/boost/1788862). To meet this
need, variant has for most of its life used the double storage technique
proposed some time ago by Anthony Williams (see
http://aspn.activestate.com/ASPN/Mail/Message/boost/1314807).
After some further consideration, I've decided to follow Dave Abraham's
suggestion and replace variant's double-storage technique with a heap-backup
scheme (see http://aspn.activestate.com/ASPN/Mail/Message/boost/1789195).
Disadvantages:
* When used, variant assignment uses operator new, which incurs significant
overhead and also may throw std::bad_alloc
* More complex visitation implementation in general. I don't yet know if
this translates to worse compile- or run- time performance.
Advantages:
* Overhead only if assignment occurs instead of constant overhead of double
storage
* Reduced compile-time complexity needed to "disable" use of scheme
Any feedback is welcome, but I primarily wanted to alert the list of these
changes. (I plan to update the documentation, as well.)
Thanks,
Eric
P.S. The basic idea of the change is as follows, given assignment lhs = rhs:
Backup content of lhs onto heap
Destroy content of lhs
Attempt copy of content of rhs to storage of lhs
If failed:
- Copy backup pointer to storage of lhs
- Indicate lhs now stores heap-allocated content
- Rethrow exception
If succeeded:
- Delete backup
- Indicate lhs now stores some new type of stack-allocated content
Note that the above does not apply under the following conditions: if the
content of lhs is of the same type as that of rhs; if the first bounded type
of lhs is nothrow default-constructible; or if the content of rhs is nothrow
copyable/movable. In these cases, other methods are used to maintain the
minimum basic exception-safety guarantee for variant.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk