From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-08-09 11:27:28
On Friday 09 August 2002 07:12 am, Anthony Williams wrote:
> Sorry, that's not what I meant. The variant would have _storage_ for two
> instances, but only contain one at a time. When swapping the variants, you
> can copy-construct the other variant into the unused space in this variant,
> then copy-construct this variant into the unused space in the other one. If
> everything has succeeded, destruct the originals, and change the flags. If
> anything failed, destruct the new copies (if any) and leave the flags
> Obviously, you need to account for alignment, and with variant it is a bit
> more complex in the implementation due to the multiple types, but the idea
> is the same.
We now have three distinct allocation strategies with different exception &
1) Stack allocation. May become empty if an exception is thrown during
assignment/swap (basic guarantee). Takes minimal stack space & will be most
2) Your strategy. Strong guarantee (no ugly "empty" state). Still
stack-allocated, but takes twice the minimum space. As efficient as (1)
3) Heap allocation. Strong guarantee, but uses heap allocation (less
efficient than the other two because of new/delete calls).
Go ahead, someone say the "P" word.
> Also, if you want assignment to actually perform assignment on the
> underlying type, rather than just transfer the value into the variant, then
> things are more complicated.
I don't really see this as a problem. Most of the time copy construction is
used in assigment operators anyway (because a no-throw swap is often
available), so not actually using the underlying assignment operator wouldn't
be a great departure from the norm.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk