Fernando Cacciola writes: > > ----- Original Message ----- > From: "Anthony Williams" <[EMAIL PROTECTED]> > To: "Boost mailing list" <[EMAIL PROTECTED]> > 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
