Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 00/12] Remove some ALL_* iteration macros
Date: Thu, 03 Jan 2019 22:45:00 -0000	[thread overview]
Message-ID: <a8759517b8595f51fc308d3a01431a23@simark.ca> (raw)
In-Reply-To: <87y381v2iu.fsf@tromey.com>

On 2019-01-03 16:45, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:
> 
> Simon> I was wondering if you had thought about replacing, for example
> Simon>   ALL_COMPUNITS (objfile, s)
> Simon> with an equivalent like this
> Simon>   for (compunit_symtab *s : all_compunits 
> (current_program_space))
> Simon> in order to avoid nested loops like
> [...]
> 
> Yeah, I don't think I really considered it.
> 
> Simon> I am not sure which one I like best.  The flat version reduces
> indentation, but
> Simon> the nested version makes it clear and explicit how the data is
> represented, so
> Simon> it might help readers who are less familiar with the code.
> 
> Same for me.  Maybe I lean a bit toward the explicit form but that 
> might
> only be because I already have the patch in hand.
> 
> Simon> Also, in theory, according to the coding style, we should write
> Simon> for (...)
> Simon>   {
> Simon>     for (...)
> Simon>       {
> Simon>         ...
> Simon>         ...
> Simon>       }
> Simon>   }
> 
> I thought it was ok to leave a single statement unbraced, though I
> personally never do this for something like:
> 
>    for (...)
>      if ...
>      else...
> 
> ...since I think that's less readable than the braced version.
> 
> If the braces are needed then that probably argues for a smarter
> iterator, to avoid excessive indentation.

They are needed if we want to strictly follow the GNU coding style:

https://www.gnu.org/prep/standards/standards.html#Clean-Use-of-C-Constructs

I think what you did is easy to read, since it's pretty straightforward. 
  We could always make an exception for these constructs, but it would 
probably end up being confusing to understand and explain when you can 
omit the braces and when you can't.

If we end up using "smarter iterators" (for the lack of a better name) 
they could be overloads:

/* Iterate on all compunits of an objfile.  */
... all_compunits (objfile *);
/ Iterate on all compunits of a program space.  */
... all_compunits (program_space *);

And let's say that all_compunits (program_space *) returns tuples of 
<objfile *, compunit_symtab *>, we'll be able to use structured bindings 
when we switch to C++17 :).  Something like:

for (const auto &[objfile, compunit] : all_compunits (pspace))

Simon


  reply	other threads:[~2019-01-03 22:45 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-25 16:54 Tom Tromey
2018-11-25 16:54 ` [PATCH 10/12] Remove ALL_OBJFILES and ALL_FILETABS Tom Tromey
2018-11-25 16:54 ` [PATCH 09/12] Remove ALL_OBJFILE_FILETABS Tom Tromey
2018-11-25 16:54 ` [PATCH 01/12] Introduce all_objfiles and next_iterator Tom Tromey
2018-11-25 16:54 ` [PATCH 12/12] Remove ALL_OBJFILE_PSYMTABS Tom Tromey
2018-11-25 16:54 ` [PATCH 03/12] Remove most uses of ALL_OBJFILES Tom Tromey
2018-11-25 16:54 ` [PATCH 05/12] Remove ALL_MSYMBOLS and ALL_OBJFILE_MSYMBOLS Tom Tromey
2018-11-25 16:54 ` [PATCH 11/12] Remove ALL_OBJSECTIONS Tom Tromey
2018-11-25 16:54 ` [PATCH 04/12] Remove ALL_OBJFILES_SAFE Tom Tromey
2018-11-25 16:54 ` [PATCH 08/12] Remove ALL_COMPUNIT_FILETABS Tom Tromey
2018-11-25 16:54 ` [PATCH 07/12] Remove ALL_COMPUNITS Tom Tromey
2018-11-25 16:55 ` [PATCH 06/12] Remove ALL_OBJFILE_COMPUNITS Tom Tromey
2018-11-25 16:55 ` [PATCH 02/12] Remove ALL_PSPACE_OBJFILES Tom Tromey
2018-12-23  7:00 ` [PATCH 00/12] Remove some ALL_* iteration macros Joel Brobecker
2018-12-24 20:54   ` Tom Tromey
2018-12-26 17:30     ` Simon Marchi
2018-12-26 22:28       ` Tom Tromey
2018-12-26 22:32         ` Tom Tromey
2018-12-26 22:35           ` Simon Marchi
2018-12-26 22:52             ` Tom Tromey
2018-12-26 23:45               ` Tom Tromey
2018-12-27  0:46                 ` Simon Marchi
2018-12-27  6:22                   ` Tom Tromey
2018-12-27  1:52 ` Simon Marchi
2019-01-03 21:46   ` Tom Tromey
2019-01-03 22:45     ` Simon Marchi [this message]
2019-01-06 20:10       ` Tom Tromey
2019-01-09 19:49         ` Simon Marchi
2019-01-10  1:29           ` Tom Tromey
2019-01-10 16:45         ` Pedro Alves
2019-01-10 18:10           ` Tom Tromey
2019-01-10 19:58             ` Pedro Alves
2019-01-10 16:44 ` Pedro Alves
2019-01-10 18:06   ` Tom Tromey
2019-01-10 18:09     ` Pedro Alves
2019-01-10 22:53       ` Tom Tromey

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=a8759517b8595f51fc308d3a01431a23@simark.ca \
    --to=simark@simark.ca \
    --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