Re: [boost] Formal review: Optional library

From: Anthony Williams (anthony.williamsNOSPAM_at_[hidden])
Date: 2002-12-13 08:46:07

Fernando Cacciola writes:
 > 
 > ----- Original Message -----
 > From: "Anthony Williams" <anthony.williamsNOSPAM_at_[hidden]>
 > To: "Boost mailing list" <boost_at_[hidden]>
 > Sent: Tuesday, December 10, 2002 9:46 AM
 > Subject: Re: [boost] Formal review: Optional library
 > 
 > 
 > > Fernando Cacciola writes:
 > > Given empty(), I see no need for peek() _and_ get_value() --- if you can
 > get a
 > > reference to the value, you can get its address, if necessary.
 > >
 > Only if the optional<> is initialized.
 > peek() returns NULL in case the optional<> is uninitialized,
 > saving the user from having to test for it separately.
 > 
 > In fact, the whole point of pointer semantic is to allow the user to
 > deal with the uninitialized case conveniently, without having to
 > test empty() (or whatever) explicitely all the time.

It doesn't really help, though --- to do anything useful with the pointer, you
have to check for NULL anyway, so it's not that different.
 
 > >
 > > I prefer the member interface to the non-member interface, in this
 > instance.
 > >
 > I don't. Member functions are tightly coupled with class types.
 > As I said earlier, the usages of optional<> easely allows the code to
 > replace
 > optional<> with bare pointers.
 > This wouldn't be possible if member functions were used.

Bare pointers have quite different properties --- for one, they don't contain
the pointed-to object.

However, if you want to go down that route, then I think you ought to have an
interface as close to that of a smart pointer (such as boost::shared_ptr or
boost::scoped_ptr) as possible --- though the fact that optional<> will
contain the pointed-to object will have to affect the interface in some
way. This should be the only difference though.

Anthony
-- 
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely response.