220 23718 <5697E95A.2020903@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: Thu, 14 Jan 2016 19:30:50 +0100 Lines: 117 Approved: news@gmane.org Message-ID: <5697E95A.2020903@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> <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 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1452796261 7044 80.91.229.3 (14 Jan 2016 18:31:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Jan 2016 18:31:01 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBW6S362AKGQEY6MQ2GY@isocpp.org Thu Jan 14 19:30:53 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f72.google.com ([74.125.82.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aJmfd-0005b3-1E for gclcip-std-proposals@m.gmane.org; Thu, 14 Jan 2016 19:30:53 +0100 Original-Received: by mail-wm0-f72.google.com with SMTP id f206sf107284532wmf.0 for ; Thu, 14 Jan 2016 10:30:52 -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:content-transfer-encoding :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=Xajb0kTeHi/FcYZldKWKX4uDLB1wriHiilXco/w0+nc=; b=vfvbgcSfglI8caRLupjGC6PYrRnkBeKgTMRmynfYoOIaU2KMu51utXFjmGet1+QNAI aFRfFWl0Iu85Aupw28Y5S0qzkeHzoMznyBTbm0hP7U0m9Z4z1Fv3bVx+0xj/Hi+3aQzG PQfyWeTIAFPkDurJHjN/g58cFZ8f2w+LloF5cKka8XEvuVorLj0KFfqAyoXcYbZG6EPK dwzwNSZoG8fJi6S4DlwibukplDkjBFhKwzLQRLbFn2Kh0/QrLDeX+8BG/ADQHJglrVy5 3jkcqGWNzDjHsfEZsCTale6fgVMG4i8UjXOUC+IjSaj67xk0lkXg2ctxiptWQ 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 :content-transfer-encoding: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=Xajb0kTeHi/FcYZldKWKX4uDLB1wriHiilXco/w0+nc=; b=bJQMGkCFFu/aOt8PA6/hkhsqFFJk/WTXBvU7lfkWMW+rrp+UxxquTYiLkC873EfRdw uxlgeOUOAh27VPGhw3GF9fsomsbO2v8WyOf9SKBTB8GKYH6cTM/cKLjnao9pTQHertTj FOJUIbogZ99mEjOcOG+sWvgdYUP07HAQ24vahj5LACfOrbjRYhOBAxNGFvfo8HEXXLms GJnvuG2PL1/5wSsbPewI4rDTapNXIIxF4zV+oat4aRaohowYk+pg7yxRz+p4nWDZzr5q m9RHNbGgsSG2OXdct+Cem1wP0GLDUfXtPysoZOOqIO7Gl59 X-Gm-Message-State: ALoCoQmCMVoHM3g0ppasQdtUxDkZgT596KVSr3y+r0KnqJwN6jy3zMYaxFVSd0Po4D/lHhJsZv6ofTGAt7mBbFkvlXrMhsLThw== X-Received: by 10.28.47.198 with SMTP id v189mr742503wmv.1.1452796252456; Thu, 14 Jan 2016 10:30:52 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.158.73 with SMTP id h70ls1137563wme.35.canary; Thu, 14 Jan 2016 10:30:51 -0800 (PST) X-Received: by 10.28.189.11 with SMTP id n11mr35240271wmf.3.1452796251305; Thu, 14 Jan 2016 10:30:51 -0800 (PST) Original-Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr. [80.12.242.128]) by mx.google.com with ESMTPS id u8si11321584wje.114.2016.01.14.10.30.51 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 14 Jan 2016 10:30:51 -0800 (PST) Received-SPF: neutral (google.com: 80.12.242.128 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.128; Original-Received: from new-host.home ([92.139.160.222]) by mwinf5d64 with ME id 5uWq1s00Y4oBxcU03uWqsD; Thu, 14 Jan 2016 19:30:51 +0100 X-ME-Helo: new-host.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Thu, 14 Jan 2016 19:30:51 +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: <753EF830-97D0-4653-B056-BDB2CD4B0760@gmail.com> X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.128 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:23718 Archived-At: Le 14/01/2016 00:09, Howard Hinnant a =C3=A9crit : > On Jan 13, 2016, at 5:13 PM, Vicente J. Botet Escriba wrote: >> 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 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. >> >> Given >> >> template >> struct is_uniquely_represented> >> >> =20 >> : public std::bool_constant::value && >> >> is_uniquely_represented >> ::value && >> >> =20 >> sizeof(T) + sizeof(U) =3D=3D sizeof(std::pair)> >> { >> }; >> >> the following should be correct >> >> static_assert(not is_uniquely_represented>::value,= ""); >> >> >>> 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: >>> >>> >>> https://github.com/HowardHinnant/hash_append/blob/master/hash_append.h#= L203-L212 >>> >>> >>> 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. >> >> I believe however that we can identify a good subset of simple classes t= hat satisfy the semantics of is_uniquely_represented. >> >> 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 >> >> 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. > 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. Yes, I see it now. So that there shouldn't be any trouble specializing=20 it with a default. > >> 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. > Sorry, I=E2=80=99m not understanding this last question. Could you give = an example? Thanks. > > The question was if it is worth specializing the is_uniquely_represented=20 even if the subset of classes for which it can be done safely is small. 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/. .