From: Eric Friedman (ebf_at_[hidden])
Date: 2003-08-30 17:38:31
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.
> 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...
> (**) 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.
Thanks,
Eric