Re: [boost] Re: Re: Mini-review request: aligned_storage.hpp

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