[boost] Re: variant questions

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