$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-12-12 13:59:11
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.
[...]
> 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.
> 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.