From: David Abrahams (dave_at_[hidden])
Date: 2003-08-30 20:57:17
"Eric Friedman" <ebf_at_[hidden]> writes:
> David Abrahams wrote:
>> 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
I meant in the implementation.
>> (**) You can specify it so that there are many ways to avoid that
>> - 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk