From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65371 invoked by alias); 10 Jul 2018 09:47:00 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 65349 invoked by uid 89); 10 Jul 2018 09:46:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=Eventually X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 10 Jul 2018 09:46:57 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id E504AAD36; Tue, 10 Jul 2018 09:46:54 +0000 (UTC) Date: Tue, 10 Jul 2018 09:47:00 -0000 From: Richard Biener To: Trevor Saunders cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH][RFC] Make iterating over hash-map elide copying/destructing In-Reply-To: <20180710091537.GH28660@ball> Message-ID: References: <20180710091537.GH28660@ball> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2018-07/txt/msg00473.txt.bz2 On Tue, 10 Jul 2018, Trevor Saunders wrote: > On Tue, Jul 10, 2018 at 10:43:20AM +0200, Richard Biener wrote: > > > > The following makes the hash-map iterator dereference return a pair > Value&> rather than a copy of Value. This matches the hash-table iterator > > behavior and avoids issues with > > > > hash_map > > > Eventually somebodies probably going to want > hash_map>, auto_vec> too, so we might as well go ahead > and make it pair? > > > where iterating over the hash-table will call the auto_vec destructor > > when dereferencing the iterator. I note that the copy ctor of > > auto_vec should probably be deleted and the hash-table/map iterators > > should possibly support an alternate "reference" type to the stored > > Values so we can use vec<> for "references" and auto_vec<> for > > stored members. > > I think code somewhere uses the auto_vec copy ctor to return a auto_vec, > this is pretty similar to the situation with unique_ptr in c++98 mode. > > > But that's out of scope - the patch below seems to survive minimal > > testing at least. > > > > I suppose we still want to somehow hide the copy ctors of auto_vec? > > I suspec the best we can do is delete it in c++11 mode and provide a > auto_vec(auto_vec &&) move ctor instead. Though I think for the > case where auto_vec has inline storage we should be able to just delete > the copy ctor? > > > How does hash-map growth work here? (I suppose it doesn't...?) > > Yeah was going to ask, I think hash_table memcpy's the elements? in > which case memcpying a pointer into yourself isn't going to work. It doesn't work. It uses assignment but auto_vec doesn't implement that so auto-storage breaks. So you say it should use std::move<> where that's obviously not available for us :/ > However I think if you use the auto_vec specialization for 0 internal > elements that should be able to work if we null out the old auto_vec or > avoid running dtors on the old elements. Well, then I don't really need auto_vec, I'm more interested in the embedded storage than the destructor ;) > > Any further comments? > > other than using a reference for the key type seems good. OK, I suppose it should be 'const Key&' then (hopefully that works for Key == const X / X * as intended). I guess given the expansion problem I'm going to re-think using auto_vec for now :/ Can we please move to C++11? ;) Richard.