[boost] Re: Yet another Variant class

From: Itay Maman (itay_maman_at_[hidden])
Date: 2002-06-29 14:26:01

Douglas Gregor wrote:
>On Friday 28 June 2002 01:50 pm, Itay Maman wrote:

>>I think that variant_cast<> should be the only way 
>>for an application code to reach the T* pointer. 
>>Consequently, get_ptr() should be made
>>private, although I must add an #ifdef-ed workaround

>>for MSVC.
>
>
>I'm happy with that. Personally, I would strongly 
>discourage the use of variant_cast anyway because it 
>is the only mechanism to access a variant that is 
>not guaranteed to succeed at run-time. Visitors are 
>typesafe as would be a switch-on-type construct.

(Following this line) Then, what do you think about
getting rid of variant_cast? This, obviously,
contradicts the "variant with an any-like interface"
feature, but it might have one major positive effect:
It requires any-based code to be rewritten in a safer
manner.

>1) Great Stack_Holder::swap :)
>
>>I am wondering if there's a more efficient way for
>>implementing an exception-safe swap() ?
>
>For the general case, I don't think there is. There
>are tons of optimization opportunities for special
>cases:
>
>  1) Same type: cast and swap
>  2) Both incomplete types: swap pointers
>  3) Both POD types: swap the bytes

Il'l add this to my "to do" list

What about the mpl::list? The compilation time (GCC
3.0.4) was a killer. I see these options:
   (1) Offer a choice between mpl::list and
Loki::typelist
   (2) Use mpl::list only
   (3) Add a Loki-like, reduced, typelist library to
variant.hpp. The user will have the choice, with
mpl::list being the default

Personally, I am in favour of (3). Rationale: (1) is
not acceptable since Loki is not part of boost, and
(2) might discourage many potential users.

-Itay.

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com