From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id +dlgHGaC82kmjAYAWB0awg (envelope-from ) for ; Thu, 30 Apr 2026 12:25:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1777566310; bh=nXk7DeEzGT9n5pX7zFE3JPdPnWNcBe/OFs15OZ9mifE=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=GfgcBXMTYg+SbyRqe39yY/AEHaMCE3xRWra0bpkd3LzAeIjHonzVWHEQcRbDwjhVr 8qOI8dSSgNTG9056EdPo2D1AS9fhtENC+T2Mj9xr20z5i+cfvgiV70ts6ilWMoXABA FVDNUddH3lyxpv6h52pSkhVryzxniToa7Ic0bxqo= Received: by simark.ca (Postfix, from userid 112) id 5BFD91E067; Thu, 30 Apr 2026 12:25:10 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=xBTN6mwd; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 7A6B41E067 for ; Thu, 30 Apr 2026 12:25:09 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 9D1AC436A07A for ; Thu, 30 Apr 2026 16:25:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9D1AC436A07A Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=xBTN6mwd Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 60B80436A040 for ; Thu, 30 Apr 2026 16:24:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 60B80436A040 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 60B80436A040 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777566279; cv=none; b=hov38s4nT/StF4aK1yL+axdEElzX7G+N9pMH1GTNSsTbZSA6coRtLcMfbNdQbz9daQXmT2BcBX3Ik+mnVc5e+ktqQCbCEERYJz1V3WUWhPuOSongliaAKU2V2VFhTUASSkHM9BjU22fxQvjWDpsBIPgU4LCIdrKwZeuDhSRMK3w= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777566279; c=relaxed/simple; bh=nXk7DeEzGT9n5pX7zFE3JPdPnWNcBe/OFs15OZ9mifE=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=rtT4wtL4kVlqVzVhAGNLjtTItvePGYmz2c8ey3qMgsakaYTAM/c1NrxN+l1aAp/NIiFxHqNZXBruoX+lR7WgNNChiDxhfKW86M5f3/d75lM45UrDP/ELqIiAnv1+O7ZauuNvpuy3BgSRdqihjk7b5mlSWWP2dFsBjAM6eU+sRK8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 60B80436A040 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1777566277; bh=nXk7DeEzGT9n5pX7zFE3JPdPnWNcBe/OFs15OZ9mifE=; h=Date:Subject:To:References:From:In-Reply-To:From; b=xBTN6mwdOjn4hhkO1zL8vVLqbFPGgpynn9GljeLIW0PIM4OMa/F0VfagYmcPdLufB V4T7tJULEPP1tPocnU5Szh+bRaJEpSzn18PWoYnC1EarxwINTS6+luNa1UjoWb5//e HXaiNE1d2RmmNyuMlRmso+xomkmBF4TO/uD7Us0w= Received: by simark.ca (Postfix) id 8B1411E067; Thu, 30 Apr 2026 12:24:37 -0400 (EDT) Message-ID: <52ebd2ce-a27b-4cf6-81f4-ad3fa3537ee1@simark.ca> Date: Thu, 30 Apr 2026 12:24:36 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/7] [gdbsupport] Factor out base_next_iterator To: Tom de Vries , gdb-patches@sourceware.org References: <20260423063530.1074175-1-tdevries@suse.de> <20260423063530.1074175-4-tdevries@suse.de> From: Simon Marchi Content-Language: fr In-Reply-To: <20260423063530.1074175-4-tdevries@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 4/23/26 2:35 AM, Tom de Vries wrote: > diff --git a/gdbsupport/next-iterator.h b/gdbsupport/next-iterator.h > index 0c90428d349..1dee941a252 100644 > --- a/gdbsupport/next-iterator.h > +++ b/gdbsupport/next-iterator.h > @@ -21,27 +21,43 @@ > > #include "gdbsupport/iterator-range.h" > > -/* An iterator that uses the 'next' field of a type to iterate. This > - can be used with various GDB types that are stored as linked > - lists. */ > +/* An iterator base class for iterating over a field of a type. In order to > + form a functioning iterator, classes inheriting this should define an > + operator++, which determines the actual field that is iterated over. > + > + Instead of factoring out a base class, we could use something like this: > + > + template > + struct next_iterator > + { > + ... > + self_type &operator++ () > + { > + m_item = m_item->*F; > + return *this; > + } > + ... > + } > + > + but that has the drawback that it doesn't work with incomplete T. */ I'm of the opinion that this information is not really relevant here, it belongs to the commit message. I was initially skeptic that the version with the pointer-to-member didn't work, so I tried it for myself and indeed, I don't think it would work with the block and superblock_iterator relationship (at least, if we want to have a method of block returning a superblock_iterator/range). While next_iterator is "iterate using the raw field `next`", base_next_iterator is more generic just for "iterating over a field of a type". It looks like you defined a pretty generic class where the derived class only needs to fill in operator++ (and perhaps a bit more boilerplate). But operator++ doesn't have to just follow a field, it can have any logic in there, as function_block_iterator proves, which is nice. Following the raw `next` field (or another raw field of any other name) is just one specific case. Given that all the concrete iterate needs to provide is "given a reference to the current element, give me the next element", I think we could reduce the boilerplate needed at each site by having the concrete iterator provide a functor that does the increment (much like you defined an std::map by providing a "hash" functor, not by deriving from std::map). Rather than copy paste what I mean here, I pushed what I think it could look like to the users/simark/next-iterator branch. https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/simark/next-iterator https://sourceware.org/cgit/binutils-gdb/log/?h=users/simark/next-iterator But just to illustrate here is how the function block iterator and range are implemented: /* Iterator and range type to iterate over this block and its superblocks within a function. */ struct function_block_incrementer { const block *operator() (const block &b) const noexcept { /* If the current item is the function-defining block, we're done. */ if (b.function () != nullptr) return nullptr; return b.superblock (); } }; using function_block_iterator = base_next_iterator; using function_block_range = iterator_range; I kept the name `base_next_iterator`, we could perhaps find a better name, since it's not realted to `next_iterator` more than any other concrete instance. Perhaps `base_iterator`, or `simple_iterator`? > @@ -61,15 +77,34 @@ struct next_iterator > return m_item != other.m_item; > } > > - self_type &operator++ () > +protected: > + > + T *m_item; > +}; > + > +/* An iterator that uses the 'next' field of a type to iterate. This > + can be used with various GDB types that are stored as linked > + lists. */ > + > +template > +struct next_iterator : base_next_iterator { > + typedef next_iterator self_type; > + typedef T *value_type; > + typedef T *&reference; > + typedef T **pointer; I think we should use `using` instead of typedef everywhere now. > + > + explicit next_iterator (T *item) > + : base_next_iterator (item) > { > - m_item = m_item->next; > - return *this; > } > > -private: > + next_iterator () = default; Just noting that instead of those two constructors, you can use: using base_next_iterator::base_next_iterator; Simon