[boost] Re: In-place construction for variant

From: Eric Friedman (ebf_at_[hidden])
Date: 2003-10-27 20:49:33

Anthony Williams wrote:

> Eric Friedman <ebf_at_[hidden]> writes:
> 
>>Double storage has been replaced by the above-described temporary heap
>>backup strategy so as to incur overhead only when/if variant assignment
>>occurs (vs. the constant space inefficiency incurred by double storage).
> 
 >
> I obviously missed the discussion where this was decided; I don't like this
> solution. I felt that a strong part of the design was that no heap storage was
> used, and so using it for assignment violates that principle, and is IMO
> unacceptable.

It seemed a lot more users felt double storage was unacceptable...

>>Heap backup will not be used for assignment to a variant if the content type
>>of the right-hand side is nothrow copyable.
>>
>>As well, heap backup will never be used for assignment to a
>>variant<T1,...,TN> if *any* of its bounded types Ti are nothrow
>>default-constructible. (Note, this is regardless of the content of the
>>right-hand side.)
> 
> 
> This, OTOH, seems thoroughly sensible. You don't want overhead that you don't
> need, and you only want the basic guarantee.
 >
> If users don't want double-storage, then they can supply a
> no-throw-default-constructible type (such as boost::empty) as a valid variant
> type, or they can use something like boost::any if heap storage is acceptable.

Try this instead:

   If users don't want [temporary heap backup], then they can supply a
   no-throw-default-constructible type (such as boost::empty) as a valid
   variant type.

(As an aside, I don't think the "they can use something like 
boost::any..." is a good answer. There are plenty of reasons to use 
boost::variant instead of boost::any -- only one of which is an increase 
in efficiency.)

Now let me say something new.

Over the past few days, I've thought of implementing const_variant, 
which would provide the same interface as variant (indeed, variant would 
be likely implemented in terms of const_variant). However, as 
const_variant would not allow assignment, it would not have to deal with 
any of the double-storage, temporary heap backup, etc. solutions.

Of course, while const_variant addresses the "why do I have to pay for 
double storage if I never use assignment?" objection, it still leaves 
the question of what is the best strategy for the variant that allows 
assignment.

Since I increasingly believe that this is an example of the "no right 
answer" phenomenon, I think a policy-based solution -- as much as I have 
dreaded such -- may be the ultimate answer.

However, neither const_variant nor a policy-based variant will be 
available in the Boost 1.31 release. While the current implementation 
may unfortunately prevent adoption by some users in this release cycle, 
it is fortunately just that: an implementation issue that can be changed 
without affecting backward compatibility.

Thanks for reading :)

Eric