From: Eric Friedman (ebf_at_[hidden])
Date: 2003-08-30 17:38:31
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.
> 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
> (**) 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
I'll try to get an implementation based on this idea running soon so we can
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk