[boost] Re: In-place construction for variant

From: Anthony Williams (anthony.williamsNOSPAM_at_[hidden])
Date: 2003-10-28 04:39:39

Eric Friedman <ebf_at_[hidden]> writes:
> 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...

Acknowledged. I just feel that using heap storage is against one of the
original principles behind the design.

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

Fair comment.

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

Probably useful. Just to confirm --- the constness of const_variant refers to
the fact that it contains the same (non-const) object for its whole lifetime,
not that it contains a const object, right?

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

Possibly. A "variant" is just a "const_variant" with an assignment policy,
whether that policy is automatically determined, or explicitly specified.

> Thanks for reading :)

Thanks for responding to my comments.

Anthony
-- 
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely response.