Boost logo

Boost :

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-08-30 10:33:55


----- Original Message -----
From: Vesa Karvonen <vesa.karvonen_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, August 29, 2001 9:47 PM
Subject: Re: [boost] optional vs variant vs any

> [SNIP]
>
> What do you think about the following table?
>
> default: ctor | type | state
> -----------------------+----------+--------+-------
> optional<t> | lazy | t | empty
> any | lazy | void | empty
>
> Notes:
> - 'optional' and 'any' can be 'empty'.
>
I see a subtle difference here (very subtle perhaps)

'any' can be empty.
'optional' can be uninitialized, not empty.

'any' is like a one-element bag, I can put in whatever I want (one thing at
a time) or I can leave it 'empty'.
I can even remove the element from it, leaving it in 'empty' state again.

optional just starts out uninitialized because the default constructor
doesn't assign any value in it.
It is the only state an optional can be created (there isn't any constructor
to initialize it with a value).
But as soon as you assign it a value, it is initialized for good; you can't
uninitialize it.

I think 'empty' applies to a container-like object wich can have or not
elements, at any time.

>
> I was mainly thinking of the following syntax:
>
> !x ...meaning... x.empty()
> if (x) ...meaning... if (!x.empty())
>
> And possibly:
>
> 0 == x ...meaning... x.empty()
> x == 0 ...meaning... x.empty()
>
> However, the usefulness of the above syntax is not very clear. It seems to
me
> that 'vswitch' and 'cast' are the proper ways to use 'variant' and
probably
> 'any', too.
>
otional support both syntaxes above.
However, I think that the second form only applies to optional (or not even
to it) because you can only use operator*() to access its value.

Furthermore, since optional offers pointer semantic I think that it should
support the second form (I think I managed to support it safetly).

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk