Re: [boost] Formal review: Optional library

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-12 15:19:18

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Thursday, December 12, 2002 3:59 PM
Subject: Re: [boost] Formal review: Optional library

> From: "Fernando Cacciola" <fernando_cacciola_at_[hidden]>
> > From: "Peter Dimov" <pdimov_at_[hidden]>
> > > True, swap()'s guarantees depend on the type. If T provides a
> > > nothrow/strong/basic swap, optional<T>::swap should be at least
> > > nothrow/strong/basic, respectively. I think that this can be done
> provided
> > > that T(T const &) is strong and T::~T is nothrow.
> > >
> > I still have to tink about this ...
>
> This is how it works in my mind:
>
> if(both uninitialized)
> {
> // do nothing, nothrow
> }
> else if(one initialized, one not)
> {
>     lhs.reset(*rhs); // strong
>     rhs.reset(); // nothrow
> }
> else // both initialized
> {
>     using std::swap;
>     swap(*lhs, *rhs);
> }
>
> It doesn't even need friendship.
>
I see.
Q: This code is supposed to be in boost::swap( optional<T>&, optional<T>&)?

> [...]
>
> > optional<> is not intended to replace _all_ situations were optional
> values
> > are used.
> > It is itended to be used on those situations were pointers are difficult
> to
> > use;
> > but I expect programmers to keep using pointers were appropriate.
> > For example, as I said before, optional arguments to a function should
not
> > be coded
> > with optional<> but with conventional pointers.
>
> Actually (just a minor observation)
>
> void f(optional<T> /*const &*/ opt);
>
> is different than
>
> void f(T const * pt);
>
> as the latter might potentially store 'pt' while the former cannot.
>
? You mean that the code inside f() could hold onto 'pt'?
Well, yes it can... but that would be nasty.
It is supposed to know that ownership is not being handed in.
The use of a pointer is reserved to convey optionality.

> > Therefore, the shortcut which is gained by having (o1==o2) compare
values,
> > handling
> > uninitialized cases, is in itself very useful, but gives optional<> a
> > peculiarity
> > which spoils its ubiquity.
>
> Not necessarily. Please read my explanation of equivalence in the other
> post, and note that it applies to pointers, too.
>
I don't get it...

If I have:

void foo ( optional<T> x, optional<T> y )
{
  ( x == y ) ;
}

Why do you suggest to be the semantic of the comnparison?

I think that you suggest that it is:

( (!x) != (!y) ? false : ( !x ? true : ( *x == *y ) )

but in this case, replacing optional<T> with T* changes this semantic, which
is what I object.

OTOH, my definition as:  get_pointer(x) == get_pointer(y)

will not change the semantic of the comparison if optional<T> is replaced by
T*

Fernando Cacciola