[boost] Re: variant questions

From: David Abrahams (dave_at_[hidden])
Date: 2003-08-30 20:57:17

"Eric Friedman" <ebf_at_[hidden]> writes:

> David Abrahams wrote:
> [snip]
>> I understand again, thanks for reminding me.  But as I mentioned
>> earlier, this rationale *needs* to be in the variant docs.
>
> Agreed. I'm working on a "design decisions/rationale" section to be included
> in the docs that will cover this and other issues.
>
>
>> One possible approach is to say that variant assignment from one type
>> to another may incur dynamic allocation (**).
>
> This is an interesting idea. If I understand you correctly, you propose
> eliminating stack-allocated double storage in favor of stack-allocated
> single storage with dynamically-allocated 'backup' storage.

Yup.

> I suppose as well a heuristic could be employed in the implementation to
> continue using stack-allocated double storage for small types (like a small
> string optimization). This is a QoI issue more than anything else though.

Sure... or a (ahem) policy.

>> Negative "which" values mean that the storage is really holding a
>> pointer to the actual object.
>
> Do you mean storing negative 'which' values in the implementation? If so,
> ok. Otherwise, I don't believe this would be necessary for the client
> interface...

I meant in the implementation.

>
>> (**)  You can specify it so that there are many ways to avoid that
>>       allocation:
>>
>>      - include a type known to be nothrow default constructible
>>      - all types are known to have nothrow copy ctors
>>      - never assign from one kind of variant into another kind
>>      - all types are known to have a nothrow swap
>>      - ...
>>
>> I don't love this solution, but it's an idea.
>
> OK, I don't love it either, but I believe the conflicting goals variant
> seeks to unify (efficiency and safety) necessarily makes for a less than
> optimal result.
>
> I'll try to get an implementation based on this idea running soon so
> we can evaluate.

OK.  Let me also say that none of my objections to double storage are
based on measurements, just (viewed in an extreme way) on vague FUD.

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