220 21300 <1572715.jJmjmrJA0J@tjmaciei-mobl4> article Path: news.gmane.org!not-for-mail From: Thiago Macieira Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: missing hash_code result in P0029 Date: Mon, 05 Oct 2015 18:07:42 +0100 Lines: 51 Approved: news@gmane.org Message-ID: <1572715.jJmjmrJA0J@tjmaciei-mobl4> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1444064894 3711 80.91.229.3 (5 Oct 2015 17:08:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 5 Oct 2015 17:08:14 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCB4TK757YBRB364ZKYAKGQEEK4PNQY@isocpp.org Mon Oct 05 19:08:05 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f198.google.com ([209.85.217.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zj9F2-0006AY-0H for gclcip-std-proposals@m.gmane.org; Mon, 05 Oct 2015 19:08:00 +0200 Original-Received: by lbos8 with SMTP id s8sf15535014lbo.2 for ; Mon, 05 Oct 2015 10:07:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-type: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=9KTgZOj6BgrCHqrS8NaiIskmBrCKJZeen/Br69vQWgk=; b=IAckO7FDDxvon9Sq2bgqsYWtgK6QIzkyJYvt3YgPTMdWRmm18kX6Mdt9iyfggMnjZ/ 7hkf+IEF7Cu68ucg+Dl/iCRfkdyF/LVlXIImOYK+YTFhFEOls+DxNEoJ+BCxWLjsmxwn QcQ8H6eEktjUlhua/qI9Ry88kAIGvfbr7ohabCReqS+ThQ+GnTYIxfP81/X3m00Q6vqu 6OS3/gcs8tt+ZOVQOWp9SJqX/CVN3y59i1MVEgagNTZTIQfNkIJnn7jN4xIadWNjRYl4 UDfUt1WGa9KGuZQ4wsb182Qc8PzbNi9XW+Yn1wj+nb23a5Ca8P/y0WqtV7/uo6H10ACB aMuQ= X-Gm-Message-State: ALoCoQnxijH3PQuqcbI6yQuRkiu0UtFRhfkgnLwcKGaQK/dpTG9esCTHBEGQKO9WjaTAjSDAtP55 X-Received: by 10.194.156.193 with SMTP id wg1mr5507422wjb.3.1444064879540; Mon, 05 Oct 2015 10:07:59 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.89.8 with SMTP id bk8ls888915wib.52.gmail; Mon, 05 Oct 2015 10:07:58 -0700 (PDT) X-Received: by 10.180.24.102 with SMTP id t6mr13155557wif.83.1444064878697; Mon, 05 Oct 2015 10:07:58 -0700 (PDT) Original-Received: from gondolin.macieira.info (gondolin.macieira.info. [78.47.120.188]) by mx.google.com with ESMTP id ex16si17644910wid.58.2015.10.05.10.07.58 for ; Mon, 05 Oct 2015 10:07:58 -0700 (PDT) Received-SPF: pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) client-ip=78.47.120.188; Original-Received: from tjmaciei-mobl4.localnet (jfdmzpr02-ext.jf.intel.com [134.134.137.71]) by gondolin.macieira.info (Postfix) with ESMTPSA id 0162B11B5A2 for ; Mon, 5 Oct 2015 10:07:58 -0700 (PDT) User-Agent: KMail/4.14.9 (Linux/4.1.6-1-desktop; KDE/4.14.9; x86_64; ; ) In-Reply-To: X-Original-Sender: thiago@macieira.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) smtp.mailfrom=thiago@macieira.org 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:21300 Archived-At: On Monday 05 October 2015 09:17:45 'Geoffrey Romer' via ISO C++ Standard - Future Proposals wrote: > The API for extracting a hash value, and symmetrically the API for > initializing the HashCode, is deliberately left unspecified. So if I want to write a new portable container that relies on hashing, I can't? What's the rationale for that? > In the case of > std::hash_code it doesn't matter, because only std::hash needs to be aware > of those details. Most definitely not. I started with an example that disagrees with this perspective. > Other HashCode types can provide similar functor > wrappers, or explicitly specify those APIs however they choose. So if I write my own element type T, I need to specify its hashing function for std::unordered_map and SomeOtherHash? > The initialization API is unspecified because it depends on the > implementation details of the HashCode (e.g. hashing::farmhash needs a > pointer to its state as an input). The value-extraction API is unspecified > because it's unsafe: in many cases it will leave the HashCode in an > unusable state. I solved that in the prototype by making it rvalue-ref > qualified, but then I realized there's no need to specify it at all > (particularly when the initialization API is also unspecified), and an > unspecified API is simpler, safer, and harder to bikeshed. > > I had thought I spelled this out in the paper somewhere, but I can't > immediately find it, so that may be an oversight on my part. I find that those reasons invalidate the proposal. If I can't use them in my own hashing container, they're unusable. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -- --- 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/. .