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.