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
> I don't. Member functions are tightly coupled with class types.
> As I said earlier, the usages of optional<> easely allows the code to
> 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 Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk