220 10265 <47dce9b0-cdc6-4bf9-8ea5-34526854d0e6@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: Thu, 17 Apr 2014 15:19:18 -0700 (PDT) Lines: 91 Approved: news@gmane.org Message-ID: <47dce9b0-cdc6-4bf9-8ea5-34526854d0e6@isocpp.org> References: <36091227-9aa0-4202-b221-5d4a0ec9b92e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_916_19459996.1397773158988" X-Trace: ger.gmane.org 1397773169 30757 80.91.229.3 (17 Apr 2014 22:19:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 17 Apr 2014 22:19:29 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDYZZG6PQYFRBZ5GYGNAKGQEYEWFWUA@isocpp.org Fri Apr 18 00:19:22 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f198.google.com ([209.85.214.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WaueP-0000dj-Oh for gclcip-std-proposals@m.gmane.org; Fri, 18 Apr 2014 00:19:22 +0200 Original-Received: by mail-ob0-f198.google.com with SMTP id va2sf5218071obc.5 for ; Thu, 17 Apr 2014 15:19:20 -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=0L1PwOZ9Kx6sIN6gqzuqqq9Uuj18uw/fLvHsJ0l7j5g=; b=O1Sk0KE9oVhF5aJLzcxaw6pZ1DKpZygZpdzAC+7r380BwQcE5rzZT1Y33+fWmXGHgW ACYeTgHV2yUXc93YvI1Q+XST0XWB84OTtIGgbaQqloSMhW/m42FeJ05SXVnbeaHbutlX 3Ei/XSDrDIANeD8GpR/vcoK9KJZq2xEsYzTHl3mGrwHjA8LVqdwjnop/KH68EiZDDmat SqEWAZnYfNrStAFhEfutd29A5FLLzNt27DNOKi+tG136174Xh+lJYeVbiipkEYi2+TMU /1khac06ZlUMev6G1iOzI4ZKyxCGmGSdX14nHzMz7d9AKCm5sYrNQYPO399LniXGjGm4 YzEA== X-Gm-Message-State: ALoCoQlEKUKbAG56HPtDAGweiYsa6h2UsdX4tiwiGcO1MnrKmbSqbXsqKfxD6B17hWlo1YAu5SaH X-Received: by 10.182.24.5 with SMTP id q5mr8551433obf.23.1397773160815; Thu, 17 Apr 2014 15:19:20 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.121.193 with SMTP id lm1ls424816obb.35.gmail; Thu, 17 Apr 2014 15:19:19 -0700 (PDT) X-Received: by 10.182.24.1 with SMTP id q1mr177364obf.4.1397773159680; Thu, 17 Apr 2014 15:19:19 -0700 (PDT) In-Reply-To: <36091227-9aa0-4202-b221-5d4a0ec9b92e@isocpp.org> 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:10265 Archived-At: ------=_Part_916_19459996.1397773158988 Content-Type: text/plain; charset=UTF-8 On Wednesday, April 16, 2014 12:34:29 PM UTC-5, DeadMG wrote: > > No, no it would not. Consider the original motivation in the paper- > unique_ptr and T*. Since there's already a hash specialization for > unique_ptr, you could not add one for T* later. > Ah, yeah, that would be a problem. (I assume the issue here is divergent hash specializations Better would be to use a separate trait to control which types are and are > not eligible. > If N3573 dropped the hash proposal, you could probably handle this by requiring people to write their own hashers that only accept the eligible types. 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. My original idea before seeing N3573 was to add a member function to unordered_map that retrieves the bucket associated with a particular hash value. Then I could just perform the hash myself and do the lookup of the value on my own. That's obviously not the ideal way to do this, although I do think that would be a (somewhat) useful function to have as a complement to unordered_map::bucket(const key_type&). - 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_916_19459996.1397773158988 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wednesday, April 16, 2014 12:34:29 PM UTC-5, DeadMG wro= te:
No, no it = would not. Consider the original motivation in the paper- unique_ptr<T&g= t; and T*. Since there's already a hash specialization for unique_ptr, you = could not add one for T* later.

Ah, yeah, that = would be a problem. (I assume the issue here is divergent hash specializati= ons

Better would be to use a separate trait to control which types are and = are not eligible.

If N3573 dropped the hash&= lt;void> proposal, you could probably handle this by requiring people to= write their own hashers that only accept the eligible types.

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

My original idea before see= ing N3573 was to add a member function to unordered_map that retrieves the = bucket associated with a particular hash value. Then I could just perform t= he hash myself and do the lookup of the value on my own. That's obviously n= ot the ideal way to do this, although I do think that would be a (somewhat)= useful function to have as a complement to unordered_map::bucket(const key= _type&).

- 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_916_19459996.1397773158988-- .