On Sunday 11 August 2002 03:31 am, Eric Friedman wrote:
>  Introducing move semantics is all-good and well, and I think it's
>  something Boost should "standardize" anyway, but I think we also need
>  to figure out a good way to keep the non-empty invariant for
>  boost::variant -- even when its bounded types do not provide the
>  nothrow-move guarantee.

Agreed.

>  I think the most important point, however, to draw from the proposal is
>  that the two classes would really be one and the same if the set of
>  bounded types provides nothrow-move semantics. 

There is _so_ much overlap between these two classes that I wonder why we 
should even separate them? I'm thinking of this from the perspective of 
someone who would have to write a C++ style guide: how would you lay down the 
rules w.r.t. using safe_variant vs. variant? Use safe_variant always, because 
we might not ever be able to afford the strange behavior of empty variants? 
Use variant always, because we don't care about exceptions anyway? Or, use 
safe_variant when required and variant otherwise? 

I think we should stay with one variant class. It should, by default, always 
be safe. However, because there are types that can't safely be put into a 
variant without compromising speed and/or efficiency, we should:

  1) Make a reasonable decision between the two safe storage methods (heap 
allocation vs. doubling the stack allocation). Perhaps use an heuristic such 
as: if in a variant<T1, T2, ..., TN> , type Ti is unsafe, then:
    a) if sizeof(Ti) > = sizeof(variant<T1, T2, ..., T{i-1}, T{i+1}, ..., TN>) 
then allocate Ti on the heap
    b) otherwise, allocate Ti by doubling the stack allocation.

  2) Optionally warn the user at compile-time when making this type of 
decision. This lets the performance-savvy users know if variant is being 
pessimistic so they can tweak things (see #3).

  3) Allow wrappers to designate the type of storage used. We already have 
incomplete<Ti>  for heap allocation. Perhaps a the complete list should be:
    incomplete<Ti>  or on_heap<Ti>: allocate on the heap
    on_stack<Ti> : on the stack, potentially doubling the size
    unsafe<Ti> : on the stack, without doubling, but variants may become 
singular/empty if an assignment or swap involving this type throws. 
    trivially_movable<Ti> : on the stack, and we can move with memcpy (this is 
shorthand notation for specializing some move-semantics traits)

This way we've guaranteed safety barring the presence of 'unsafe<T> '  but also 
optionally warned the user about potential efficiency issues and given 
him/her a way to manually resolve the efficiency issues on a type-by-type 
basis based on the requirements of his/her project (space may be more 
important in one area, whereas speed is more important in another).

	Doug
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost