220 23703 <5696CC0A.5040709@wanadoo.fr> article Path: news.gmane.org!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Default swap/hash_value Date: Wed, 13 Jan 2016 23:13:30 +0100 Lines: 399 Approved: news@gmane.org Message-ID: <5696CC0A.5040709@wanadoo.fr> 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000407020207060105000304" X-Trace: ger.gmane.org 1452723224 19325 80.91.229.3 (13 Jan 2016 22:13:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Jan 2016 22:13:44 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBDEY3O2AKGQEJW7Z5OY@isocpp.org Wed Jan 13 23:13:36 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f199.google.com ([209.85.217.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aJTfa-0005WK-F9 for gclcip-std-proposals@m.gmane.org; Wed, 13 Jan 2016 23:13:34 +0100 Original-Received: by mail-lb0-f199.google.com with SMTP id dx9sf23067218lbc.3 for ; Wed, 13 Jan 2016 14:13:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type: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=l15WksG0Kpgyy4o+Dq2I9EdoUzdNh+bFsP/8PmafrZc=; b=qk5JxX0TtmqmLAZYe5qlh/QCCWYJB5WYH5q7pXqxme2KIYqhpS1CjmrlyHDnQvNR3t 8KWAJUSo5Lgp9sNGpQ/GysUBDcGq5DUTuTp5lfbPa/pzsaY07O2rLhv1PgM5zI0aMrFx /VNkPDfScE87VpkoBI/a54jJhvqaWIWrCEyYOXREFBe7XwE7gBfbSCr14e8cEFjNfm4h NGLgtu473otxCD/RVY5/Y23GmVmIUh0wUj5+n0//Rrp4i+Eq57l42kRSCBK/G6lgtcSP 71ZS9ljDZQ27hPkHSpapjpwsGbDWgopWiWXKnE/MkyM/4a6mrt0ExQp+lh2yi9C8RrO7 RQvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type: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=l15WksG0Kpgyy4o+Dq2I9EdoUzdNh+bFsP/8PmafrZc=; b=OdCsP7sq2EgiKtAZ6h2VBbN7V5ibib4WPNTt2LTkOXB5II3CsvUB3NmPRohB/dhtlq Yw8rcBWeqxCbukizaGT0oVw4iycift86jwh1zqAGkOVbeOO+PGUHmD+rXKksC9pxz10E 8CWbivxy4lEJcuh0VRQMuehSsnxXX2Wa85H+crhY7yZipwG6HjFf8T060Sz6Q/bsqxLX pLnqFnjC4RwOyKY+5sVYabosKaDUO0AkOrF15P2Qbw0+02u5lGUnIsTgtUAC2j5t4DlF kQkoAYPplFTQH7OODCwQ33fYB7lvbLIj3wtB60z3RXTxNsG40PwtTCB055wNmeEOA9/P Xkbg= X-Gm-Message-State: ALoCoQnnd4S6JAoReyAanag4sQb7EjxtlVwv+qu71+Vl+PezzxUVFtGg12nd/Zo7U9o6sLdbo5wScxB5FAu8tNC1ZigV4euk/w== X-Received: by 10.25.18.99 with SMTP id h96mr61984lfi.3.1452723214019; Wed, 13 Jan 2016 14:13:34 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.46.7 with SMTP id u7ls947046wmu.27.canary; Wed, 13 Jan 2016 14:13:32 -0800 (PST) X-Received: by 10.194.222.135 with SMTP id qm7mr527258wjc.106.1452723212075; Wed, 13 Jan 2016 14:13:32 -0800 (PST) Original-Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr. [80.12.242.129]) by mx.google.com with ESMTPS id d13si41798951wma.91.2016.01.13.14.13.31 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 13 Jan 2016 14:13:32 -0800 (PST) Received-SPF: neutral (google.com: 80.12.242.129 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.129; Original-Received: from new-host.home ([92.139.160.222]) by mwinf5d14 with ME id 5aDW1s00U4oBxcU03aDXXo; Wed, 13 Jan 2016 23:13:31 +0100 X-ME-Helo: new-host.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Wed, 13 Jan 2016 23:13:31 +0100 X-ME-IP: 92.139.160.222 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <9160999F-C7E2-4D3F-B343-96CF587BEF61@gmail.com> X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.129 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr 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:23703 Archived-At: This is a multi-part message in MIME format. --------------000407020207060105000304 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 13/01/2016 17:09, Howard Hinnant a =C3=A9crit : > On Jan 13, 2016, at 3:13 AM, Vicente J. Botet Escriba wrote: >> I've some additional concerns about the possible generation of specializ= ation of is_uniquely_represented. I would like it to be generated the sp= ecialization when possible but while multiple definition of hash_value coul= d be check at link time, I believe that multiple specializations of is_uniq= uely_represented would result in ODR, which would be a showstopper. So a= t the end, it would be the responsibility of the developer of class C to ad= d a specialization of is_uniquely_represented. What do you think about t= his point? > I believe you are correct that it will be necessary for the author of C t= o specialize is_uniquely_represented. There are semantics to this prope= rty that do not show up in the C++ type system. For example the hashing of= a std::vector should never include the vector=E2=80=99s capacity(). And t= he hashing of an IEEE floating point should hash -0. and 0. to the same val= ue (despite the different bit layouts). C may have similar rules on how it= 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=20 generated. Classes like vector would define its own operator=3D=3D and so= =20 the hash automatic generation would be inhibited. If=20 is_uniquely_represented is false on IEEE floating point, classes=20 containing those as data members should be inhibited also. I believe=20 that in these cases is_uniquely_represented should not be specialized=20 neither. Given |template struct is_uniquely_represented> : public std::bool_constant::value &&=20 is_uniquely_represented::value && sizeof(T) + sizeof(U) =3D=3D=20 sizeof(std::pair)> { };| the following should be correct |static_assert(not is_uniquely_represented>::value,= =20 "");| > > In the case that is_uniquely_represented answers true, I believe it is= a simple library function to automate hash_append/hash_value. Here is an = updated N3980 implementation of such a function: > > https://github.com/HowardHinnant/hash_append/blob/master/hash_append.h#L2= 03-L212 > > If something is uniquely represented, you can ship its bytes off to the h= ash algorithm without concern about how its bases and members are laid out.= Not only is this easier than dealing with the bases and members individua= lly, it is also more efficient for most modern hash algorithms. Hash algor= ithms 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. > > I understand the optimization advantage of is_uniquely_represented.=20 Thanks for your clear paper. I believe however that we can identify a good subset of simple classes=20 that satisfy the semantics of is_uniquely_represented. My concern is if the default specialization of the trait for these=20 subset could be in conflict with a late user specialization or a=20 specialization in another translation unit Could we require that the same user specialization must appear on all=20 the translation units that see the C declaration and before the need for=20 the trait appears? After some thoughts I believe that this seems acceptable, as otherwise=20 the traits could take different values in different parts of the program=20 violating the ODR, independently of whether there is a default=20 specialization or not. It is worth doing it for this subset? This should depend on how many=20 classes belong to this subset. E.g. the specialization for std::pair=20 could be default generated. Apologies if my ideas are not clear enough Vicente --=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/. --------------000407020207060105000304 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Le 13/01/2016 17:09, Howard Hinnant a =C3=A9crit=C2=A0:
On Jan 13, 2016, at 3:13 AM, Vicente J. Botet Escriba =
<vicente.botet@wanadoo.fr> wrote:

I've some additional concerns about the possible generation of specializati=
on of is_uniquely_represented<T>. I would like it to be generated the=
 specialization when possible but while multiple definition of hash_value c=
ould be check at link time, I believe that multiple specializations of is_u=
niquely_represented<T> would result in ODR, which would be a showstop=
per. So at the end, it would be the responsibility of the developer of clas=
s C to add a specialization of is_uniquely_represented<T>. What do yo=
u think about this point?

I believe you are correct that it will be necessary for the author of C to =
specialize is_uniquely_represented<C>.  There are semantics to this p=
roperty that do not show up in the C++ type system.  For example the hashin=
g of a std::vector should never include the vector=E2=80=99s capacity().  A=
nd the hashing of an IEEE floating point should hash -0. and 0. to the same=
 value (despite the different bit layouts).  C may have similar rules on ho=
w it 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 generated. Classes like vector would define its own operator=3D=3D and so the hash automatic generation would be inhibited. If is_uniquely_represented is false on=C2=A0 IEEE floating point, classes= =C2=A0 containing those as data members should be inhibited also. I believe that in these cases is_uniquely_represented should not be specialized neither.

Given

template <class =
T, class U>
struct is_uniquely_represented<=
std::pair<T, U>>
    : public std::bool_consta=
nt<T>::value &&
                                is_uniquely_represented<U>::value &&
                                sizeof(T)=
 + sizeof(U) =3D=
=3D sizeof(std::pair<T, U>)>
{
};

the following should be correct

static_assert(n=
ot is_uniquely_represented<std::pair<float, int>>::value, "");



In the case that is_uniquely_represented<C> answers true, I believe i=
t is a simple library function to automate hash_append/hash_value.  Here is=
 an updated N3980 implementation of such a function:

https://github.com/Howard=
Hinnant/hash_append/blob/master/hash_append.h#L203-L212

If something is uniquely represented, you can ship its bytes off to the has=
h algorithm without concern about how its bases and members are laid out.  =
Not only is this easier than dealing with the bases and members individuall=
y, it is also more efficient for most modern hash algorithms.  Hash algorit=
hms like to see as many bytes as possible at once for best performance.  Th=
is leads to less buffering and more bit crunching within the algorithm.
I understand the optimization advantage of is_uniquely_represented. Thanks for your clear paper.

I believe however that we can identify a good subset of simple classes that satisfy the semantics of is_uniquely_represented.

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 in another translation unit

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 trait appears?
After some thoughts I believe that this seems acceptable, as otherwise the traits could take different values in different parts of the program violating the ODR, independently of whether there is a default specialization or not.

It is worth doing it for this subset? This should depend on how many classes belong to this subset. E.g. the specialization for std::pair could be default generated.

Apologies if my ideas are not clear enough

Vicente

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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-proposals= /.
--------------000407020207060105000304-- .