220 23704 <753EF830-97D0-4653-B056-BDB2CD4B0760@gmail.com> article Path: news.gmane.org!not-for-mail From: Howard Hinnant Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Default swap/hash_value Date: Wed, 13 Jan 2016 18:09:33 -0500 Lines: 115 Approved: news@gmane.org Message-ID: <753EF830-97D0-4653-B056-BDB2CD4B0760@gmail.com> References: <569582E5.1040108@wanadoo.fr> <4072A7C6-B09D-4847-971B-2914643B91D7@gmail.com> <569594AD.6000505@wanadoo.fr> <2170C30C-830F-47C2-8397-29DD4ED35E97@gmail.com> <56960730.9000403@wanadoo.fr> <9160999F-C7E2-4D3F-B343-96CF587BEF61@gmail.com> <5696CC0A.5040709@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1452726586 7161 80.91.229.3 (13 Jan 2016 23:09:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Jan 2016 23:09:46 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCK2HM4L6YERBMFS3O2AKGQEOM7NJDA@isocpp.org Thu Jan 14 00:09:42 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f198.google.com ([209.85.213.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aJUXr-0004Nz-69 for gclcip-std-proposals@m.gmane.org; Thu, 14 Jan 2016 00:09:39 +0100 Original-Received: by mail-ig0-f198.google.com with SMTP id mw1sf469484258igb.0 for ; Wed, 13 Jan 2016 15:09:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=T9mYcCDOX/+bzENXAqYc3PIkHcQq4hCmjtk4YC0ziA0=; b=dZkglYi/EWlfiJ9Q6pBjMDSaVUCQqSOt5amcZxPiiwhGz6ipzTR+EYL73aPfWqK9k3 8Gx8kMtOO4uOevOhqrVppfPGWXTthyJC2yT65wvixPT/B7jWm1fIJsbr0eYXidXU/zdZ RUh6dbiMwe8uzhFcysk9RB3clAPS9g20yjzJoYIW4Dm5zbfo+q9eo4OdjScFxFGSv7BZ hKLUTz07GODFzlpwyHpcMjImuB0bGffqY6MVNtSnoqSZ2q7RTQEKfEKD3elXMvIm4zXe Q2oppVOBFJaGrzJNFVOI1NAfhsY4G9r7DZrQZx/UZdz0y1lQfYi+8zYlmUf4hRcIM16J X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=T9mYcCDOX/+bzENXAqYc3PIkHcQq4hCmjtk4YC0ziA0=; b=M5cqKQz/ntykVUo4gJS2AdOZgQhwqxnDCcyMSzw5TPZwMMlix7KpHOzPUR7+qNPFwH LJKa2ZFXKj32C201fZdEN3E8iUThnPtajDqV9HYkXKsNaXa+6kJvYQXw1vxSgvr+/mh+ K+cBdW5KQ3ObbfLwgKa6xe6OGze9MvzSzxzJiWF4ztxE/FAUYkzxMVbVVDMWlP1SI8l7 fv7wZ+xlsDWpuDYqShsS9309bNLJdN3l8oXQ9MtL+/gLcHS7soM67O3cs+7lDrFRVxQq e3rK+7cdgHOwfjxVYakgQDH0k2eXKEWa+u+T03RobshCJAU0IGTcevCyOOlW6Uu8v5Uc X-Gm-Message-State: ALoCoQmWljKBqp54qJ64c6mwyeMyihM23Zo/5eiNchPn957cE8EOsgIAyQJtcguyPp5y3/6Vunc9YrvCqN/nLZUn8s9rOAB7xQ== X-Received: by 10.182.240.226 with SMTP id wd2mr907730obc.0.1452726578076; Wed, 13 Jan 2016 15:09:38 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.96.230 with SMTP id k93ls114794qge.78.gmail; Wed, 13 Jan 2016 15:09:36 -0800 (PST) X-Received: by 10.55.207.82 with SMTP id e79mr1054354qkj.102.1452726576636; Wed, 13 Jan 2016 15:09:36 -0800 (PST) Original-Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com. [2607:f8b0:400d:c04::232]) by mx.google.com with ESMTPS id g3si3858279qkb.15.2016.01.13.15.09.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jan 2016 15:09:36 -0800 (PST) Received-SPF: pass (google.com: domain of howard.hinnant@gmail.com designates 2607:f8b0:400d:c04::232 as permitted sender) client-ip=2607:f8b0:400d:c04::232; Original-Received: by mail-qg0-x232.google.com with SMTP id o11so467384710qge.2 for ; Wed, 13 Jan 2016 15:09:36 -0800 (PST) X-Received: by 10.140.20.80 with SMTP id 74mr1052594qgi.15.1452726576535; Wed, 13 Jan 2016 15:09:36 -0800 (PST) Original-Received: from [10.0.1.2] (cpe-104-229-168-124.twcny.res.rr.com. [104.229.168.124]) by smtp.gmail.com with ESMTPSA id n90sm1387706qkl.46.2016.01.13.15.09.34 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 13 Jan 2016 15:09:34 -0800 (PST) In-Reply-To: <5696CC0A.5040709@wanadoo.fr> X-Mailer: Apple Mail (2.3112) X-Original-Sender: howard.hinnant@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of howard.hinnant@gmail.com designates 2607:f8b0:400d:c04::232 as permitted sender) smtp.mailfrom=howard.hinnant@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:23704 Archived-At: On Jan 13, 2016, at 5:13 PM, Vicente J. Botet Escriba wrote: >=20 > Le 13/01/2016 17:09, Howard Hinnant a =C3=A9crit : >> On Jan 13, 2016, at 3:13 AM, Vicente J. Botet Escriba >> wrote: >>=20 >>> I've some additional concerns about the possible generation of speciali= zation of is_uniquely_represented. I would like it to be generated the s= pecialization when possible but while multiple definition of hash_value cou= ld be check at link time, I believe that multiple specializations of is_uni= quely_represented would result in ODR, which would be a showstopper. So = at the end, it would be the responsibility of the developer of class C to a= dd a specialization of is_uniquely_represented. What do you think about = this point? >>>=20 >> I believe you are correct that it will be necessary for the author of C = to specialize is_uniquely_represented. There are semantics to this prop= erty that do not show up in the C++ type system. For example the hashing o= f a std::vector should never include the vector=E2=80=99s capacity(). And = the hashing of an IEEE floating point should hash -0. and 0. to the same va= lue (despite the different bit layouts). C may have similar rules on how i= t must be hashed and only the author of C can know this. > The idea is to restrict to classes for which the operator=3D=3D is genera= ted. Classes like vector would define its own operator=3D=3D and so the has= h automatic generation would be inhibited. If is_uniquely_represented is fa= lse on IEEE floating point, classes containing those as data members shou= ld be inhibited also. I believe that in these cases is_uniquely_represented= should not be specialized neither. >=20 > Given >=20 > template > struct is_uniquely_represented> >=20 > =20 > : public std::bool_constant::value && >=20 > is_uniquely_represented > ::value && >=20 > =20 > sizeof(T) + sizeof(U) =3D=3D sizeof(std::pair)> > { > }; >=20 > the following should be correct >=20 > static_assert(not is_uniquely_represented>::value, = ""); >=20 >=20 >>=20 >> In the case that is_uniquely_represented answers true, I believe it i= s a simple library function to automate hash_append/hash_value. Here is an= updated N3980 implementation of such a function: >>=20 >>=20 >> https://github.com/HowardHinnant/hash_append/blob/master/hash_append.h#L= 203-L212 >>=20 >>=20 >> If something is uniquely represented, you can ship its bytes off to the = hash algorithm without concern about how its bases and members are laid out= .. Not only is this easier than dealing with the bases and members individu= ally, it is also more efficient for most modern hash algorithms. Hash algo= rithms like to see as many bytes as possible at once for best performance. = This leads to less buffering and more bit crunching within the algorithm. >>=20 >>=20 >>=20 > I understand the optimization advantage of is_uniquely_represented. Thank= s for your clear paper.=20 >=20 > I believe however that we can identify a good subset of simple classes th= at satisfy the semantics of is_uniquely_represented.=20 >=20 > My concern is if the default specialization of the trait for these subset= could be in conflict with a late user specialization or a specialization i= n another translation unit >=20 > Could we require that the same user specialization must appear on all the= translation units that see the C declaration and before the need for the t= rait appears? > After some thoughts I believe that this seems acceptable, as otherwise th= e traits could take different values in different parts of the program viol= ating the ODR, independently of whether there is a default specialization o= r not. I agree that this is a reasonable (and necessary) requirement. is_uniquely= _represented would not be the first user-specializable trait. We=E2=80=99v= e been doing this sort of dance since C++98 with iterator_traits. >=20 > It is worth doing it for this subset? This should depend on how many clas= ses belong to this subset. E.g. the specialization for std::pair could be d= efault generated. Sorry, I=E2=80=99m not understanding this last question. Could you give an= example? Thanks. Howard --=20 ---=20 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 e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos= als/. .