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.