220 10269 <1e5bc048-1785-4883-9aeb-9d6e995db7eb@isocpp.org> article Path: news.gmane.org!not-for-mail From: Jim Porter Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: N3573: Why heterogenous extensions to unordered containers will not work Date: Sat, 19 Apr 2014 08:46:48 -0700 (PDT) Lines: 98 Approved: news@gmane.org Message-ID: <1e5bc048-1785-4883-9aeb-9d6e995db7eb@isocpp.org> References: <36091227-9aa0-4202-b221-5d4a0ec9b92e@isocpp.org> <47dce9b0-cdc6-4bf9-8ea5-34526854d0e6@isocpp.org> <661FAB3A-689D-4E10-AF8E-E129305A9968@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_76_31921248.1397922408586" X-Trace: ger.gmane.org 1397922418 7825 80.91.229.3 (19 Apr 2014 15:46:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 19 Apr 2014 15:46:58 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDYZZG6PQYFRB2NUZKNAKGQEBOBMRWI@isocpp.org Sat Apr 19 17:46:53 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f200.google.com ([209.85.213.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WbXTf-0006yw-5O for gclcip-std-proposals@m.gmane.org; Sat, 19 Apr 2014 17:46:51 +0200 Original-Received: by mail-ig0-f200.google.com with SMTP id l13sf2118667iga.7 for ; Sat, 19 Apr 2014 08:46:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=a97NvsHBozUQyj3ZctW9nV7J9f2B1Xss/3Vhwnr+mnk=; b=A5WYnCuW4YxN3LcOoYiar+NcV7prFX/uqA/uL4Zl29p60HVZQG6WmI73xj9p7jgV6q ROFXWUtJaZFxJ6JrXAaGzagsX4ZD0AjeRU834S/gvdVS0OHu6RU0OMs6OpRgdEg2fyBd yGkYbR64rsHKa21J6Dt2nUkgup9FJGTKK1K3rzCzbTTV6So2IsQ2/l2eh0IRPznYUs93 X61YugOoQgrqxxPqUv935wcjCEtAwwoXd/t2WBRWK4asnYAJ5dq8QNhnTV+948vngxon 7VIHWsUgotZ3CzigNM6BmbAAm73DA16qEcQgT2RtVCAAHQAXtieTO2lWXb+6d8N3OPI+ xPzw== X-Gm-Message-State: ALoCoQlqL/eaDQdk3pYDghr0um6laOMBSfcgtrsOw2/j4m4+O56PqfQYkFQAEH8UyraUJNWT5LOf X-Received: by 10.42.209.18 with SMTP id ge18mr7361408icb.7.1397922410294; Sat, 19 Apr 2014 08:46:50 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.182.106 with SMTP id ed10ls600954obc.90.gmail; Sat, 19 Apr 2014 08:46:49 -0700 (PDT) X-Received: by 10.182.1.129 with SMTP id 1mr239949obm.6.1397922409353; Sat, 19 Apr 2014 08:46:49 -0700 (PDT) In-Reply-To: <661FAB3A-689D-4E10-AF8E-E129305A9968@gmail.com> X-Original-Sender: jvp4846@g.rit.edu 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:10269 Archived-At: ------=_Part_76_31921248.1397922408586 Content-Type: text/plain; charset=UTF-8 On Friday, April 18, 2014 9:52:41 AM UTC-5, Howard Hinnant wrote: > > On Apr 17, 2014, at 6:19 PM, Jim Porter > > wrote: > > > Maybe I should explain the use case I care about at the moment: I have a > map whose key_type is a tuple of value types, but I want to be able to > perform lookups on the map with a tuple of reference types. Implementing my > own hash function that just combines the hashes of the tuple's members > would be totally acceptable for me. > > With this proposal: > > > http://htmlpreview.github.io/?https://github.com/HowardHinnant/papers/blob/master/hashing.html > I suppose this would still have the problem mentioned in the original post, namely that uhash<>{}(1.0) != uhash<>{}(1). However, I think this would resolve DeadMG's issue by providing a specification for what data is hashed for each type. Thus, you wouldn't have divergent specializations of hash functions (or at least, it would be no more likely than writing an "evil" less-than operator). There'd still need to be some way of explicitly enabling the heterogeneous extensions to unordered_map, though. - Jim -- --- 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/. ------=_Part_76_31921248.1397922408586 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Friday, April 18, 2014 9:52:41 AM UTC-5, Howard Hinnant= wrote:
On Apr 17, 2014, at 6:1= 9 PM, Jim Porter <jvp...@g.rit.edu<= /a>> wrote:

> Maybe I should explain the use case I care about at the moment: I = have a map whose key_type is a tuple of value types, but I want to be able = to perform lookups on the map with a tuple of reference types. Implementing= my own hash function that just combines the hashes of the tuple's members = would be totally acceptable for me.

With this proposal:

http://htmlpreview.github.io/?https://github.com/HowardHinnant/papers/blob/master/hashing.html=

I suppose this would still have the problem menti= oned in the original post, namely that uhash<>{}(1.0) !=3D uhash<&= gt;{}(1). However, I think this would resolve DeadMG's issue by providing a= specification for what data is hashed for each type. Thus, you wouldn't ha= ve divergent specializations of hash functions (or at least, it would be no= more likely than writing an "evil" less-than operator).

There'd sti= ll need to be some way of explicitly enabling the heterogeneous extensions = to unordered_map, though.

- Jim

--

---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_76_31921248.1397922408586-- .