"Rob Stewart" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > From: David Abrahams <[EMAIL PROTECTED]> > > 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 <[EMAIL PROTECTED]> > > List-Help: <mailto:[EMAIL PROTECTED]?subject=help> > > List-Archive: <http://lists.boost.org/MailArchives/boost> > > List-Unsubscribe: <http://lists.boost.org/mailman/listinfo.cgi/boost>, > > <mailto:[EMAIL PROTECTED]?subject=unsubscribe> > > List-Subscribe: <http://lists.boost.org/mailman/listinfo.cgi/boost>, > > <mailto:[EMAIL PROTECTED]?subject=subscribe> > > List-Post: <mailto:[EMAIL PROTECTED]> > > List-Id: Boost mailing list <boost.lists.boost.org> > > Sender: [EMAIL PROTECTED] > > > > "William E. Kempf" <[EMAIL PROTECTED]> 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. > 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: http://groups.yahoo.com/group/boost/files/optional2.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 [EMAIL PROTECTED] > Software Engineer http://www.sig.com > Susquehanna International Group, LLP using std::disclaimer; > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
