Boost logo

Boost :

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.


> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at