Re: [boost] Formal review: Optional library

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-10 13:44:57

----- 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:
>  >
>  > ----- 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,
>  > the
>  > > >> 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
>  > guess
>  > > >> 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
>  > interface.
>  > (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.
>
Yes, and that's why I didn't call it empty() :-)
See my reponse to William

> 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.

>
> 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.

> 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
> optional<>.
>
I definitely will need something to increase exception safety in optional<>.
That could be your technique (the double-buffer right?), or Eric Friedman's
Move Library
which he will submit eventualy.
At this point it appears to me that Eric's move traits would be better on
average because
it won't require double storage; though I know your technique, OTOH,
gives the strong guarantee in *all* cases and not just the average.
But we'll have time to talk about this once Eric's move library is on the
table.

> In any case, I say ACCEPT the library.

Great!

Fernando Cacciola