From: Itay Maman (itay_maman_at_[hidden])
Date: 2002-06-11 10:25:11
Douglas Gregor wrote:
[snip]
> We've discussed this quite a bit, but we have yet to
see a full implementation
> for review. This is probably because there are many
features we would like to
> see in a variant type. I've started a Wiki page to
build a requirements
> document, and populated it with those requirements
that I recall from
> previous discussions. The Wiki page is here:
>
>
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Variant
>
It's nice to know I am not the only one who thinks a
type-list based union is a good idea :)
> Here's the current requirements list from the Wiki
page:
>
> * Interface should support construction and
assignment from any of the
> types that the variant can hold.
What about automatic casting from non-specified types?
(For example: initializing a union of <float, string>
with a double value). Personally, I think this
behavioral detail should be specified by a policy.
In general, I see four separate, policy-controlled,
aspects:
1) Storage: (i) boost::any (ii) on-stack
2) Automatic casting: (i) never, (ii) cast to the
first type possible, (iii) cast if only one possible
type found
3) Assignmenmt error: (i) Compile-time error, (ii)
initialize with default value of first type
The fourth aspect relates to the issue of variant to
variant assigmnet:
Variant<List1> u1;
Variant<List2> u2;
...
u1 = u2; //Problem(?): u2's held type may be
invalid
// for assignment into u1
4) Variant to variant assigmnet error: (i)
Compile-time error if List2 is not a sub set of List1.
(ii) Run-time error (iii) assign the default value of
the first type on List1
[snip]
>
> * Recursive types should be allowed, i.e., a
variant can hold a value of a
> type that is constructed using the variant type
> * Incomplete types should be allowed.
Can you clarify on these two points?
[snip]
>
> As for your actual proposal:
> - The name Super_union is uninformative (what's
'super' about it?). I
> personally prefer just 'variant', but I'm sure there
are other good names as
> well.
I used 'Super_union' as a "project name" which
specifies a concrete implementation. As for the final
name of this component, I agree with you: 'variant' is
most appropriate.
>
> - The visitor is fine, but there are simpler
syntactic constructs that could
> be used. For instance, instead of 'visit_at' just
use the function call
> operator.
The function call operator cannot be static, which is
somewhat restrictive.
> Also, the 'Visitor' class can be an implementation
detail with a
> (more natural?) syntax like:
> Super_union<...> u0;
> // ...
> u0.visit(size_visit());
>
This syntax is indeed more natural, when the visit
policy is stateless. However, if we make go() to
return *this, we end up with a very clean way for
applying the operation to multiple objects:
typedef Super_union<The_list> Concrete_union;
Concrete_union::Visitor<size_visit>::type
size_visitor;
// ...
int result =
size_visitor.go(u0).go(u1).go(u2).total_;
Thoughts?
-Itay
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com