Boost logo

Boost :

From: Rob Stewart (stewart_at_[hidden])
Date: 2002-12-17 16:46:57


> From: David Abrahams <dave_at_[hidden]>
> Date: Sun, 15 Dec 2002 10:29:23 -0500
> Content-Type: text/plain; charset=us-ascii
> X-Mailman-Version: 2.1b3
> Reply-To: Boost mailing list <boost_at_[hidden]>
> List-Help: <mailto:boost-request_at_[hidden]?subject=help>
> List-Archive: <http://lists.boost.org/MailArchives/boost>
> List-Unsubscribe: <http://lists.boost.org/mailman/listinfo.cgi/boost>,
> <mailto:boost-request_at_[hidden]?subject=unsubscribe>
> List-Subscribe: <http://lists.boost.org/mailman/listinfo.cgi/boost>,
> <mailto:boost-request_at_[hidden]?subject=subscribe>
> List-Post: <mailto:boost_at_[hidden]>
> List-Id: Boost mailing list <boost.lists.boost.org>
> Sender: boost-bounces_at_[hidden]
>
> "William E. Kempf" <wekempf_at_[hidden]> writes:
>
> > Fernando Cacciola said:
> >
> >> However, and very unfortunately, this _requires_ the properly well
> >> defined relational operators to be disallowed, because they can
> >> effectively create practical problems if optional is mistaken for a
> >> pointer and used, for example, to test for aliased equivalence as you do
> >> when you compare pointers.
> >
> > So, just to keep pointer-like operations you're going to make the
> > interface difficult to use for many valid use cases?
>
> My feeling, FWIW, is that usefulness should trump mis-usability in
> this case. I'd rather see deep relational operators and a
> pointer-like interface, than to see one or the other sacrificed just
> because we think it might confuse people. The arguments for each of
> these interfaces has been made with sufficient force here to convince
> me that we should keep them.

I certainly find Fernando's argumentation in favor of operator
*() and operator ->() compelling. The pointer interface
certainly models well what optional is doing. Indeed, I consider
optional's primary value to be its handling of the case that a
value might not be available.

I can see some value in using deep relops with optionals, since
that means a simple expression can handle the optional aspect and
do the same comparison on the underlying values if present.
However, one can argue that that is operator abuse. There are
those that find operator overloading too confusing, so optional
will certainly be an example for them if you keep the deep
relops.

I don't find deep relops compelling. An optional isn't a value.
Any code that would use it like a value is wrong, unless it is in
a restricted context in which the value is known to be
available. I think the superior interface requires one to
"dereference" the optional before making comparisons as it
eliminates a class of errors without making things much more
verbose.

However, I would be in favor of a functional comparison
approach. How about this:

template <typename T>
int compare(
   optional<T> const & lhs_i, optional<T> const & rhs_i);

(It can be a mf, too.)

This function can have the deep relop behavior Peter has
outlined, whereas optional could support either no relops or
those using state comparison semantics only.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk