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
> 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.
> 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
> 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 Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk