----- Original Message ----- From: "Peter Dimov" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Wednesday, December 11, 2002 5:47 PM Subject: Re: [boost] Formal review: Optional library
> From: "Fernando Cacciola" <[EMAIL PROTECTED]> > [...] > > (1) deep-constantness: > > > > I Followed David Abraham's suggestion and decoupled > > constantness of the optional<> object with that of > > the value being wrapped. > > This is how pointers and most smart pointers work, so > > the pointer semantic should suffice to explain this behaviour. > > Hm. Did Dave really suggest that? :-) > Sort of. He said that if optional<> is supposed to offer pointer semantics then it should not provide deep constantness simply because pointers don't do that. > To reiterate, my opinion is that deep constness is much more appropriate for > optional<>. Constness and copying go hand in hand: deep copy corresponds to > deep constness, and shallow copy corresponds to shallow constness. > Optional<> does a deep copy. Even smart pointers that do deep copy use deep > const. > Good point. Let me check if I followed your logic: optional<T> opt(v) does a 'copy' of the 'v'; it does not hold onto the 'v' itself as if it were given a handle. So it clearly has deep copy semantics. Your argument is that since it has deep copy semantics, it should have deep-constantness too, right? > > > template<class T> > > class optional > > { > > [...] > > > void swap ( optional& rhs ) ; > > Doesn't the standard std::swap do the job, by the way? > With the current implementation, yes, it does. But if optional<> is eventually changed to use an implementation with stronger exception guarantees, wouldn't it require a member swap()? That's the reason I put it there. > [...] > > > } ; > > > > template<class T> inline T* get ( optional<T> const& opt ) ; > > Why the free function? > On the user code I **really** prefer to write: get(opt) instead of opt.get() becasue I like to decouple from class types as much as possible. Perhaps this could be called get_pointer() as shared_ptr<> does. > > > > template<class T> inline void swap ( optional<T>& x, optional<T>& y ) ; > > [...] > > This is utterly important now that is has safe_bool, > > because IMO, Tanton Gibbs interpretation is correct; > > given safe_bool: > > > > optional<int> opt0 ; > > optional<int> opt1 ; > > > > (opt0 == 0 ) // true > > (opt1 == 0 ) // true > > > > therefore.... > > > > (opt0 == opt1) HAS TO BE TRUE. > > > > > > If the comparison above is properly understood, > > that is, if it is clear that the initialized states > > are being compared and not the values, then there is > > no problem, but considering that: > > > > optional<int> opt0(1); > > optional<int> opt1(2); > > (opt0 == opt1) // true > > > > is also true even though the values are different, > > I think that allowing direct comparions will > > create unneccesary confusion. > > I think that the comparisons we were discussing as a possible candidate > required both the initialized states and the held values to match. > > This is consistent with the "optional as a container of zero/one" and the > "optional as a value with an additional unitialized state" models. > I don't follow 'exactly' Can you elaborate? Fernando Cacciola _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost