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
>  alone.
[snip example]
>  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 & 
performance characteristics:

  1) Stack allocation. May become empty if an exception is thrown during 
assignment/swap (basic guarantee). Takes minimal stack space & will be most 
efficient otherwise.

  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.
> 
>  Anthony

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.

	Doug
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost