From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-17 17:15:36
"Rob Stewart" <stewart_at_[hidden]> wrote in message
> > 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
> > >> 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
> 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
Well, I more or less feel the same about deep relops, but I am convinced now
that there are those who would really like to have them, so the last
version, which I attahed in my last post yesterday, includes deep relops.
> 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);
Sort of this is provided in the last version, as 'equal_pointees()'.
BTW: This last version can be found as a _different_ zip:
-- Fernando Cacciola > (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; > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk