From: Anthony Williams (anthony.williamsNOSPAM_at_[hidden])
Date: 2002-12-10 07:46:39
Fernando Cacciola writes:
> ----- Original Message -----
> From: "Glen Knowles" <gknowles_at_[hidden]>
> To: "'Boost mailing list'" <boost_at_[hidden]>
> Sent: Monday, December 09, 2002 6:42 PM
> Subject: RE: [boost] Formal review: Optional library
> > From: Fernando Cacciola [mailto:fernando_cacciola_at_[hidden]]
> > >>
> > >> * I'm unsure about the presence of "initialized()". On the one hand,
> > >> duplication in features (compared to "get/peek() == 0") is something I
> > >> think designs should generally avoid. On the other hand, this name is
> > >> more meaningful for what precisely "get/peek() == 0" signifies. I
> > >> I'm +0 on this one.
> > >>
> > >To be honest, I dislike it too :-)
> > >But some people found the alternative spellings ugly,
> > >so I figured that a member function would make them happy.
> > How about using !empty() instead of initialized() ?
> The problem William was raising is not about the particular name of the
> member-function: empty() or initialized(); but about having a(nother)
> member-function to do a job which is already covered by other parts of the
> (note that there is no empty() member function in optional<>)
> OTOH, whether to have 'empty' or 'initialized'... well, I prefer
> 'initialized', but that's mainly a matter of personal taste I think.
empty() is analogous to containers.
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.
I prefer the member interface to the non-member interface, in this instance.
You might like to use the techniques from my StrongStorage class (see the
boost files section on yahoo) to ensure integrity in the face of exceptions
--- StrongStorage actually provides a very minimal implementation of
In any case, I say ACCEPT the library.
-- 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