From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-08-30 09:18:00
----- Original Message -----
From: Vesa Karvonen <vesa.karvonen_at_[hidden]>
Sent: Wednesday, August 29, 2001 5:06 PM
Subject: [boost] optional vs variant vs any
> Now, if understand 'variant' correctly, then it seems to me that
> could be implemented something like this (without run-time overhead on an
> ideal, but not "magical", compiler):
> template<class t>
> struct optional
> variant<t,void> v;
Interesting note. I should think about this.
> - optional: signaling errors/uncomputable results, lazy
> - variant: safe union ???
> - any: typeless programming (it seems like a "boxed value")
> - smart pointer: avoiding resource leaks/automatic finalization, exception
I've also used optional to pass optional parameters.
With the comments already added by Douglas and Kevlin, I think your tables
> I think that all of the above concepts should be further refined. For
> - 'any' could probably make use of the 'vswitch' syntax.
I think any variant type could use this syntax. My own variant_t<> could use
> - 'variant<T,void>' seems very close to 'optional<T>'.
Don't know for sure.
variant<T,empty> v ;
implies that v can hold a value of type T or type empty (or void, if that
would be possible).
According to variant semantics, it should be possible to assign empty() to
So the empty type isn't any special; it just some sort of type that variant
optional<T> opt ;
on the other hand, can only have type T. It dosen't have a second
In other words, you cannot 'uninitialize' opt, which would be equivalent to
v = empty();
That is, I think that a variant which might have a 'void' type value isn't
exactly the same as a value that might be uninitialized.
> Assuming that optional and variant make it into Boost, I think that Boost
> should have documentation which describes the differences between these
> concepts and should perhaps include a decision tree for choosing the best
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk