220 4308 article Path: news.gmane.org!not-for-mail From: Lawrence Crowl Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Fixing Standard Library relational operators (was: Re: optional Rev.4 (N3672): What was the rationale to remove !=, >=, ...) Date: Tue, 7 May 2013 15:14:37 -0700 Lines: 95 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1367964881 20897 80.91.229.3 (7 May 2013 22:14:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 May 2013 22:14:41 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCY3D77DYUDBBUHZUWGAKGQE647A2NY@isocpp.org Wed May 08 00:14:41 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yh0-f72.google.com ([209.85.213.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UZq9h-00074n-EV for gclcip-std-proposals@m.gmane.org; Wed, 08 May 2013 00:14:41 +0200 Original-Received: by mail-yh0-f72.google.com with SMTP id z6sf1485210yhz.3 for ; Tue, 07 May 2013 15:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlers.com; s=googlers; h=x-received:x-beenthere:x-received:received-spf:mime-version :x-received:in-reply-to:references:date:message-id:subject:from:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-google-group-id:list-post :list-help:list-archive:list-subscribe:list-unsubscribe:content-type; bh=0RzYces2R3vsfoWdHtEPTaFxquaXj7YaZ9Ab7goCazM=; b=VO+AcbEH7SeO6UaaBLGJW2NEKLY1Kmtu83I3rpVxLBgmmlmmMOaNtUgz9RxhIo7KPR t49+HdaYY5OZ0PYmerNLO4FQOFtyAgjG/imLplb72oB9PrLIW1HcdfU24VdCY90Z5NMo gE1yzBaOH4hHO2SInLhxak8ktwOd1ST7jpDNY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-beenthere:x-received:received-spf:mime-version :x-received:in-reply-to:references:date:message-id:subject:from:to :x-gm-message-state:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=0RzYces2R3vsfoWdHtEPTaFxquaXj7YaZ9Ab7goCazM=; b=UoodjOqfmJon/Fu3wCVcZDurmvDu63OShzn7RVnpA4bpUCNoF9OD6AyN6XK/+oxUqx CZKriF8ccVttpsSYaAbhqx8U5R1b3XMhZn08Ohd5vAMfkKyMjojEqwwlUy1GkiRulfCI eVOzCqWOeGNchhP1b3B5hfxnQfC4fhjVKAG8vYDrEq8sik5OuEU1CkaNO7w4OBcBkXvs EUe7jZhXINOJcy508c/NfApRxw+OkW+aTA6JLpzS3uMRN5qakrWJpP2Bt4Jm82+ep+jJ UYqERL/ySGuXNPvhzzMHov2X5UL3znp X-Received: by 10.236.124.226 with SMTP id x62mr2488675yhh.47.1367964880502; Tue, 07 May 2013 15:14:40 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.106.73 with SMTP id gs9ls624592qeb.27.gmail; Tue, 07 May 2013 15:14:39 -0700 (PDT) X-Received: by 10.224.214.134 with SMTP id ha6mr3061181qab.77.1367964879229; Tue, 07 May 2013 15:14:39 -0700 (PDT) Original-Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by mx.google.com with ESMTPS id q16si8332800qct.78.2013.05.07.15.14.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 15:14:38 -0700 (PDT) Received-SPF: pass (google.com: domain of crowl@google.com designates 209.85.128.54 as permitted sender) client-ip=209.85.128.54; Original-Received: by mail-qe0-f54.google.com with SMTP id q19so691035qeb.27 for ; Tue, 07 May 2013 15:14:38 -0700 (PDT) X-Received: by 10.49.71.203 with SMTP id x11mr3318455qeu.19.1367964878004; Tue, 07 May 2013 15:14:38 -0700 (PDT) Original-Received: by 10.229.197.13 with HTTP; Tue, 7 May 2013 15:14:37 -0700 (PDT) In-Reply-To: X-Gm-Message-State: ALoCoQkTAt9hiIBB+KadMRRVAn/NbQ5cmmyWoxwod1+w5VXt+CLt/POzbWm/Z4dFS0+i+WxheH/5VU+8HKxojw/WQnsGK9JIY6OGDjKxocuMRnv9hCU4B9gliskARR5P7IGLG0M3D/caZatMfOVo7IAD1kxM5LuV38ZAw8cHqkMIhGFNskp/xqgWFpRQx1NaKimhE7kXYXp/ X-Original-Sender: crowl@googlers.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of crowl@google.com designates 209.85.128.54 as permitted sender) smtp.mail=crowl@google.com; dkim=pass header.i=@googlers.com; dmarc=pass (p=NONE dis=none) d=googlers.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:4308 Archived-At: On 2 May 2013, Nevin Liber wrote: > operator< should be implemented in terms of operator< of the > underlying component(s). > operator== should be implemented in terms of operator== of the > underlying component(s). > std::less should be implemented in terms of std::less of the > underlying component(s). > std::equal_to should be implemented in terms of std::equal_to > of the underlying component(s) > > operator>, operator<=, operator>= should be written in terms of > operator<. > operator!= should be written in terms of operator==. > std::greater, std::less_equal, std::greater_equal should be > written in terms of std::less. > std::not_equal_to should be written in terms of std::equal_to On 3 May 2013, Nevin Liber wrote: > The other, simpler possibility is to not specialize the arithmetic > operations: > > operator< should be implemented in terms of std::less of the > underlying component(s). > operator== should be implemented in terms of std::equal_to of the > underlying component(s). > operator>, operator<=, operator>= should be written in terms of > operator< > operator!= should be written in terms of operator== > > This may have surprising results for those who, for instance, think > operator< and std::less should do different things (the only place > in the standard which does this as far as I know is for pointers, > and that is only because C doesn't give them a total ordering), > but I see that being as insane as NaN. There are two orderings that we need to worry about, value ordering and representation ordering. You call NaNs insane, but they are insane only because they cannot participate in a total order with other floating-point values. As such, you can have (ab) be false. In this realm, defining operator> in terms of operator< is just plain wrong. On the other hand, for purposes of associative lookup, we can impose an arbitrary total order on representations because they are strings of bits. Defining std::greater in terms of std::less is fine. On 3 May 2013, Ville Voutilainen wrote: > Agreed, the pointer situation is unfortunate, but it seems likely > that other types will have this difference between op< and less. Likewise, size 30/34 trousers are neither smaller nor larger than size 34/30 trousers. Nor are they equal. But we can still arbitrarily use the first number as more significant to association. > A further 0.02: I find it unfortunate that the operator-functors > are ever anything but alternative ways to perform their underlying > operators. It's pragmatically important that putting types into > sets and maps is easy, but making less and op< different is, from a > pedantic standpoint, a gross hack. It would be much cleaner to not > use std::less by default in maps and sets, but use some AssocComp > that invokes std::less by default, and allow specialization of > that AssocComp for funny types. I'm not sure whether that cleaner > solution is attainable, that particular cat may well be so far > out of the bag that wooing it back isn't practical. The naming is unfortunate, but the distinction between value ordering and representation ordering is fundamental and deserves explicit recognition in the language. Right now, we have the convention that value ordering is spelled operator< and representation ordering is spelled std::less. The confusion arises because the when the value ordering is total, you can use it to implement std::less without appealing to the representation. BTW, the distinction between value and representation ordering is appears in the atomic compare exchange functions, which are defined in terms of memcmp, i.e. the representation ordering. One must be careful when operating on types that have multiple representations for each value. -- Lawrence Crowl -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en. .