[boost] Re: Formal review: Optional library

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-12 17:09:53

"William E. Kempf" <wekempf_at_[hidden]> wrote in message
news:4791.167.16.75.11.1039729217.squirrel_at_frodo.kempf-ville.com...
> Fernando Cacciola said:
> > Due to some significant changes to the optional<> class, I had to upload
> > a new version so that the review can continue based on the revised
> > class.
> >
> > http://groups.yahoo.com/group/boost/files/optional.zip
> >
> > The new zip contains the new code, new test and new documentation.
> >
> > NOTE: The header optional_detail is no longer needed so you may remove
> > it before unpacking the zip.
>
> Documentation issues/questions:
>
> * "its safe on most platforms which treat null pointer dereferencing as
> undefined behaviour which is effectively a core dump or an non-language
> exception"
>
> I know what you're saying here, but I don't like it.  Undefined behavior
> is undefined behavior, and can never be considered "safe".  I'm not sure
> how to rework it to convey what you want, but I think it needs reworked.
>
OK. You're right. The wording is incorrect.

> * The "safe bool" should be documented in the same manner as it is in
> shared_ptr, i.e. "operator unspecified-bool-type() const; // never
> throws".
>
OK.
I figure that if I can borrow the implementation I can borrow the
documentation too :-)

> * Does the "assert(*opt == v)" in the description for "explicit
> optional<T>::optional( T const& v )" indicate that the type T must be
> comparable?  (I know the documentation clearly says otherwise, but it's
> not clear that this is a non-normative part of the documentation.)
>
Good question.
That form of asserts are intended to show the postconditions  that hold
after each of the operations described.
But they are not meant to imply that the type T must support the expression;
rather that if the expression is defined, then the condition must hold.
Pehaps a a note to this effect can be added before the semantics
description.

> * In the acknowledgements for Gennadiy Rozental you describe the "value
> based" implementation which no longer exists.
>
Opps! Thanks.
Anyway, after the review I will have to add several entries to this section
:-)

> Interface issues/questions:
>
> * Is there a reason for operator!() when we have the safe bool?
>
I left it because shared_ptr has it.
I figure that there must be some contexts where the safe_bool conversion
doesn't work.

> * Should you provide a templated assignment to parallel the templated
> constructor?
>
Another good question!
I can't see why not... if it is correct to have one it is correct to have
the other, IMO.

--
Fernando Cacciola