220 3683 article Path: news.gmane.org!not-for-mail From: jgottman6@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: N3573: Why heterogenous extensions to unordered containers will not work Date: Tue, 9 Apr 2013 19:22:47 -0700 (PDT) Lines: 112 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6377_22165865.1365560567186" X-Trace: ger.gmane.org 1365560567 20609 80.91.229.3 (10 Apr 2013 02:22:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 10 Apr 2013 02:22:47 +0000 (UTC) Cc: jgottman6@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD7LHGWIQEPRB6EZSOFQKGQE2XPXH7I@isocpp.org Wed Apr 10 04:22:50 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vb0-f69.google.com ([209.85.212.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UPkgU-0006z4-3v for gclcip-std-proposals@m.gmane.org; Wed, 10 Apr 2013 04:22:50 +0200 Original-Received: by mail-vb0-f69.google.com with SMTP id p12sf10231054vbe.0 for ; Tue, 09 Apr 2013 19:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:x-beenthere:x-received:date:from:to:cc:message-id :in-reply-to:references:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:x-google-group-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=X2r+5Ndti2iYio1ULdE20WmVEggAP8PqVrKxQvDdoEw=; b=BpusDLJdUGJdFzqGr5YLYwc6R/IDr8ggEwmf5iNpfzGZahCyKYMB/Qb7qSslyjkEDz 6RSl/FMkh1rM/5kiMXLj44iSW0sjc7AisThExvusJ1jMcg44bvC5NnwD6qPcdp9CGCEF 7X9ytdFfLiIzDrYMcofpGJnKLt7GvGFKyPMtPIfQirB/wl0wSqxcRW5aV+dE6MI/do3/ eaE91gb0P7ymw7yJ1cZNcqbSaFHVAIm4250eMclQo6WEvibuJbsvZKiluDV7WyBubSBG JpJpwxXOiV2oLXcHpkowhs6xcP2kG9uz+JkkKsFWal0vWzoxARedAWx0jRqNLaO8GR3b ZZ/Q== X-Received: by 10.224.65.6 with SMTP id g6mr384206qai.4.1365560569161; Tue, 09 Apr 2013 19:22:49 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.24.230 with SMTP id x6ls87671qef.31.gmail; Tue, 09 Apr 2013 19:22:47 -0700 (PDT) X-Received: by 10.49.37.39 with SMTP id v7mr5274qej.27.1365560567911; Tue, 09 Apr 2013 19:22:47 -0700 (PDT) In-Reply-To: X-Original-Sender: jgottman6@gmail.com 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:3683 Archived-At: ------=_Part_6377_22165865.1365560567186 Content-Type: text/plain; charset=ISO-8859-1 On Tuesday, April 9, 2013 6:58:15 AM UTC-4, DeadMG wrote: > > Actually, I don't believe that exact use case *is* in the paper. And, > whilst it's nice, it would depend on std::hash treating it's > argument like a C string rather than a generic pointer, and I don't know if > it does. If so, then that would certainly be a nice use case- and you could > certainly provide a custom hasher for one lookup that could perform this > using another of the features in N3573. > > Whilst I admit that I overlooked implicit conversions in this case, it's > not a breaking problem, I'll just have to provide a new name, like, find_by > or some such (and the same for erasure). That also means I'd have to use > SFINAE to limit operator[] too, since that cannot be given another name, or > perhaps some kind of trait. It would have been nice to have something like > > template void find(std::unordered_set t, U&& u) > { > t.find(u); > } > > function for any U, I doubt any such code exists, so I'm not that bothered > by losing it. > Actually, this is possible. You just need to overload operator() in your hash object. Thus, for hash>, as well as defining operator()(const unique_ptr &), you would also define operator()(X *). Then, your templated find method would always call hash>()(u), but which overload it chooses would depend on the type of u. Joe Gottman -- --- 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/?hl=en. ------=_Part_6377_22165865.1365560567186 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tuesday, April 9, 2013 6:58:15 AM UTC-4, DeadMG wrote:
Actually, I don't believe that exact use cas= e *is* in the paper. And, whilst it's nice, it would depend on std::hash<= ;const char*> treating it's argument like a C string rather than a gener= ic pointer, and I don't know if it does. If so, then that would certainly b= e a nice use case- and you could certainly provide a custom hasher for one = lookup that could perform this using another of the features in N3573.
=
Whilst I admit that I overlooked implicit conversions in thi= s case, it's not a breaking problem, I'll just have to provide a new name, = like, find_by or some such (and the same for erasure). That also means I'd = have to use SFINAE to limit operator[] too, since that cannot be given anot= her name, or perhaps some kind of trait. It would have been nice to have so= mething like

template<typename T<= /span>, typename U> void find(std::unordered_s= et<T= > t<= /span>, U&& u= ) {
  =   t.find(= u);
= }

function for any U, I doubt any such code exists, so I'm not that bot= hered by losing it.

 
Actually, this= is possible.  You just need to overload operator() in your hash objec= t.  Thus, for hash<unique_ptr<X>>, as well as defining ope= rator()(const unique_ptr<X> &), you would also define operator()(= X *).  Then, your templated find method would always call hash<uniq= ue_ptr<X>>()(u), but which overload it chooses would depend on the= type of u.

Joe Gottman

--
 
---
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-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-pro= posals/?hl=3Den.
 
 
------=_Part_6377_22165865.1365560567186-- .