[boost] Re: In-place construction for variant

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-28 21:14:29

"Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:

> "Eric Friedman" <ebf_at_[hidden]> escribió en el mensaje
> news:bnmgea$f8q$1_at_sea.gmane.org...
>> Anthony Williams wrote:
>>
>> > Eric Friedman <ebf_at_[hidden]> writes:
>> >>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?
>>
>> Yes, the content type would be immutable, while the content would be
>> mutable (unless const-qualified).
>>
>> A better name might be fixed_variant.
>>
> yea, I like this better.

Before we go adding new components just to satisfy discomfort at the
idea that heap storage might be used in some cases, we should ask
ourselves whether anyone has a use case for fixed_variant.  The only
thing it provides over the existing variant design is a runtime check
that you're not changing the type it contains.  It doesn't even
provide a compile-time check.  IMO that is not worth implementing a
new component for.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com