Re: [boost] Formal review: Optional library

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-12 11:34:57

"Peter Dimov" <pdimov_at_[hidden]> writes:

> From: "Fernando Cacciola" <fernando_cacciola_at_[hidden]>
>> > Yes, I thought about that, too. But if the current swap semantics are
>> > retained, it should simply be removed. Otherwise optional<T>::swap must
>> > offer at least swap(T&, T&)'s guarantee.
>> >
>> I'm not sure I follow.
>> What are swap(T&, T&) guarantees in general?
>> I thought this depended on the specific type.
>
> 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'm confused by this. A constructor pretty much always gives the
strong guarantee if it gives the basic guarantee.

I suppose it could have side-effects...

>> Anyway, as I posted recently, I'm just about to conclude that relational
>> operators
>> could be properly defined as a synonim for: get_pointer(o1) .relop.
>> get_pointer(o2).
>> I found this definition totally consistent with pointer semantics and the
>> implied
>> aliasings.
>
> Optional does not have pointer semantics. Two optionals can never alias each
> other. "Consistent with pointer semantics" doesn't make sense. Optional is
> not a pointer. Don't try to make it into one; you'll arrive at shared_ptr.
> ;-)

As usual, I agree with Peter

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution