From: Tom de Vries <tdevries@suse.de>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 3/7] [gdbsupport] Factor out base_next_iterator
Date: Fri, 1 May 2026 15:00:39 +0200 [thread overview]
Message-ID: <183aeea4-50ce-4f24-9c09-f35ac03a08c0@suse.de> (raw)
In-Reply-To: <87340kpbwx.fsf@tromey.com>
On 4/24/26 6:21 PM, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
> Tom> Instead, this patch factors out base_next_iterator, which contains all parts
> Tom> not specific to "next", in other words, everything except the operator++.
>
> This looks pretty reasonable to me, though I wonder if it would be
> improved using the CRTP idiom.
>
> It's not really needed but it could possibly be cleaner.
>
> https://en.cppreference.com/cpp/language/crtp
>
Thanks, I've done that in a v1 (
https://sourceware.org/pipermail/gdb-patches/2026-May/227066.html ).
> Tom> + Instead of factoring out a base class, we could use something like this:
> Tom> +
> Tom> + template<typename T, auto F = &T::next>
> Tom> + struct next_iterator
> Tom> + {
> Tom> + ...
> Tom> + self_type &operator++ ()
> Tom> + {
> Tom> + m_item = m_item->*F;
> Tom> + return *this;
> Tom> + }
> Tom> + ...
> Tom> + }
> Tom> +
> Tom> + but that has the drawback that it doesn't work with incomplete T. */
>
> I am curious about this because I wonder how the current code could work
> with an incomplete T -- since the code references T::next directly.
>
> Tom> - explicit next_iterator (T *item)
> Tom> + explicit base_next_iterator (T *item)
> Tom> : m_item (item)
> Tom> {
> Tom> }
>
> Tom> /* Create a one-past-the-end iterator. */
> Tom> - next_iterator ()
> Tom> + base_next_iterator ()
> Tom> : m_item (nullptr)
> Tom> {
> Tom> }
>
> These should probably be protected now because it doesn't make sense to
> directly instantiate a base_next_iterator.
>
I did that initially, but Simon suggested importing the constructor from
base_next_iterator, and that doesn't work if it's protected.
> Tom> +template<typename T>
> Tom> +struct next_iterator : base_next_iterator<T> {
>
> Brace placement.
>
Fixed.
> Tom> + typedef next_iterator self_type;
> Tom> + typedef T *value_type;
> Tom> + typedef T *&reference;
> Tom> + typedef T **pointer;
>
> I would have thought most of these would be inherited.
> (I guess with CRTP this could all be in the base class)
That's indeed what happened, these are gone now.
Thanks,
- Tom
next prev parent reply other threads:[~2026-05-01 13:01 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 6:35 [PATCH 0/7] [gdb] Add superblocks range loops Tom de Vries
2026-04-23 6:35 ` [PATCH 1/7] [gdb] Use block::function_block Tom de Vries
2026-04-23 14:33 ` Tom Tromey
2026-04-24 12:19 ` Tom de Vries
2026-04-23 6:35 ` [PATCH 2/7] [gdbsupport] Add parameterless iterator_range constructor Tom de Vries
2026-04-23 14:34 ` Tom Tromey
2026-04-24 12:20 ` Tom de Vries
2026-04-23 6:35 ` [PATCH 3/7] [gdbsupport] Factor out base_next_iterator Tom de Vries
[not found] ` <87340kpbwx.fsf@tromey.com>
2026-04-30 4:49 ` Tom de Vries
2026-05-01 12:54 ` Tom de Vries
2026-05-01 13:00 ` Tom de Vries [this message]
2026-04-30 16:24 ` Simon Marchi
2026-04-30 19:09 ` Simon Marchi
2026-05-01 12:57 ` Tom Tromey
2026-05-01 13:20 ` Tom de Vries
2026-05-01 13:15 ` Tom de Vries
2026-04-23 6:35 ` [PATCH 4/7] [gdb] Add block::superblocks Tom de Vries
2026-04-27 11:11 ` Jan Vrany
2026-05-01 13:06 ` Tom de Vries
2026-04-30 16:24 ` Simon Marchi
2026-05-01 13:19 ` Tom de Vries
2026-04-23 6:35 ` [PATCH 5/7] [gdb] Use block::super_blocks Tom de Vries
2026-04-24 16:27 ` Tom Tromey
2026-04-24 21:24 ` Tom de Vries
2026-04-23 6:35 ` [PATCH 6/7] [gdb] Add block::function_blocks Tom de Vries
2026-04-23 6:35 ` [PATCH 7/7] [gdb] Use block::function_blocks Tom de Vries
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=183aeea4-50ce-4f24-9c09-f35ac03a08c0@suse.de \
--to=tdevries@suse.de \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox