220 23714 <601027C6-EDBF-42C5-9AAB-766B31945702@gmail.com> article Path: news.gmane.org!not-for-mail From: Jonathan Coe Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Default swap/hash_value Date: Thu, 14 Jan 2016 17:43:16 +0000 Lines: 130 Approved: news@gmane.org Message-ID: <601027C6-EDBF-42C5-9AAB-766B31945702@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> <753EF830-97D0-4653-B056-BDB2CD4B0760@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1452793418 18301 80.91.229.3 (14 Jan 2016 17:43:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Jan 2016 17:43:38 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC2JVFPBRAHBBN54362AKGQEOUGORCI@isocpp.org Thu Jan 14 18:43:25 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f71.google.com ([209.85.215.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aJlvf-0002GU-4v for gclcip-std-proposals@m.gmane.org; Thu, 14 Jan 2016 18:43:23 +0100 Original-Received: by mail-lf0-f71.google.com with SMTP id c134sf54158949lfb.1 for ; Thu, 14 Jan 2016 09:43:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:references:in-reply-to: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=3AuL0JKUDDmQ0+CY7v+IryjoC+JweBgRjUqz+mcyu14=; b=sPXH7aQdh538XHGcx9M2VxYkSkTQnHr4zEGyw1n2dsdltB1UskaQe239D+TKVXXLMa DRa754StLhZ5m81XqG0TOfHJvUXpvdOPat+PmfMXnvKTZ+7Br1FGftrmIfTUJVT4oBd2 f8iCZx9NCOdixa3c3JN49k7uoTgDN9n7GIZA66tmiAqFqpz2LL7rkWuPQjKeitDjEV78 pchb1ganls3xyJYMdA6tWag0LF1CDTJ/tnRepQ/4IrQc2aAwYi0YK4BwX5O2qmx3Uajm 0iwXDQR6Bvr9AdRIoIcRSXaHC1gH2UZ7TYTGvmkwRQ00zEizngJXjDyBX5QTdJCxDxj5 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :mime-version:subject:message-id:date:references:in-reply-to: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=3AuL0JKUDDmQ0+CY7v+IryjoC+JweBgRjUqz+mcyu14=; b=Zdxm/FJ0jOc67OnReGnZ6daS8ul5GLu/ChQTvSyAxZ7GuSJVLkWu6GJ1J46JReZemQ iYyGOaAYQiNZnZfMlabqD3ae2FiOLM82X/a83T3t10+uWeWTzP175cG9Ga17q1FpStou 2uAujwrzmw1OxVJD704n/XJ4WZQyXnDhnHsGsd2m3uaI5Ltu2re5O9yhflf+WtpGrIYm TVORAuob9qRh+b/cXggqVkqAi9Y4eGB+vpE7AvViRtUKQrAGuoJkHEvmcyQXCRaWy3K4 kpRcqvBw2ixCAelJPZozirDT0jux2I8anNskTyZ+WQjUxJ/q9YwwAkzEHdfKlVM83xxJ X-Gm-Message-State: ALoCoQmNXzKKvg1ArZcY+G2/CLn0n/NHZgcqtSEKSeYJLb1jEtW3PH8LhBUQ4TvL+HswrAYk5Ezuuc2I9g7w670nEMfDFXqxng== X-Received: by 10.112.162.101 with SMTP id xz5mr652112lbb.20.1452793402624; Thu, 14 Jan 2016 09:43:22 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.148.201 with SMTP id w192ls1157144wmd.6.canary; Thu, 14 Jan 2016 09:43:19 -0800 (PST) X-Received: by 10.28.156.198 with SMTP id f189mr5844494wme.25.1452793399231; Thu, 14 Jan 2016 09:43:19 -0800 (PST) Original-Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com. [2a00:1450:400c:c09::243]) by mx.google.com with ESMTPS id m132si47884374wmd.38.2016.01.14.09.43.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jan 2016 09:43:19 -0800 (PST) Received-SPF: pass (google.com: domain of jonathanbcoe@gmail.com designates 2a00:1450:400c:c09::243 as permitted sender) client-ip=2a00:1450:400c:c09::243; Original-Received: by mail-wm0-x243.google.com with SMTP id f206so45154407wmf.2 for ; Thu, 14 Jan 2016 09:43:19 -0800 (PST) X-Received: by 10.28.3.134 with SMTP id 128mr5827189wmd.92.1452793398740; Thu, 14 Jan 2016 09:43:18 -0800 (PST) Original-Received: from [192.168.1.67] (host86-173-83-132.range86-173.btcentralplus.com. [86.173.83.132]) by smtp.gmail.com with ESMTPSA id di6sm7044981wjb.12.2016.01.14.09.43.17 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Jan 2016 09:43:17 -0800 (PST) In-Reply-To: <753EF830-97D0-4653-B056-BDB2CD4B0760@gmail.com> X-Mailer: iPhone Mail (13C75) X-Original-Sender: jonathanbcoe@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of jonathanbcoe@gmail.com designates 2a00:1450:400c:c09::243 as permitted sender) smtp.mailfrom=jonathanbcoe@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:23714 Archived-At: > On 13 Jan 2016, at 23:09, Howard Hinnant wrote= : >=20 >> 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 special= ization of is_uniquely_represented. I would like it to be generated the = specialization when possible but while multiple definition of hash_value co= uld be check at link time, I believe that multiple specializations of is_un= iquely_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 = add a specialization of is_uniquely_represented. What do you think about= this point? >>> 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 pro= perty 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= the hashing of an IEEE floating point should hash -0. and 0. to the same v= alue (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 gener= ated. Classes like vector would define its own operator=3D=3D and so the ha= sh automatic generation would be inhibited. If is_uniquely_represented is f= alse on IEEE floating point, classes containing those as data members sho= uld be inhibited also. I believe that in these cases is_uniquely_represente= d 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 = is a simple library function to automate hash_append/hash_value. Here is a= n updated N3980 implementation of such a function: >>>=20 >>>=20 >>> https://github.com/HowardHinnant/hash_append/blob/master/hash_append.h#= L203-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 ou= t. Not only is this easier than dealing with the bases and members individ= ually, it is also more efficient for most modern hash algorithms. Hash alg= orithms 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. Than= ks for your clear paper.=20 >>=20 >> I believe however that we can identify a good subset of simple classes t= hat satisfy the semantics of is_uniquely_represented.=20 >>=20 >> My concern is if the default specialization of the trait for these subse= t could be in conflict with a late user specialization or a specialization = in another translation unit >>=20 >> Could we require that the same user specialization must appear on all th= e 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 t= he traits could take different values in different parts of the program vio= lating the ODR, independently of whether there is a default specialization = or not. >=20 > I agree that this is a reasonable (and necessary) requirement. is_unique= ly_represented would not be the first user-specializable trait. We=E2=80= =99ve been doing this sort of dance since C++98 with iterator_traits. >=20 How will is_uniquely_represented work with architecture dependant alignment= requirements and padding? >>=20 >> It is worth doing it for this subset? This should depend on how many cla= sses belong to this subset. E.g. the specialization for std::pair could be = default generated. >=20 > Sorry, I=E2=80=99m not understanding this last question. Could you give = an example? Thanks. >=20 > Howard >=20 > --=20 >=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= email 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-prop= osals/. --=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/. .