From: Christian Biesinger <cbiesinger@google.com>
To: Luis Machado <luis.machado@linaro.org>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>,
gcc Mailing List <gcc@gcc.gnu.org>,
Pedro Alves <palves@redhat.com>, Simon Marchi <simark@simark.ca>
Subject: Re: Coding style for C++ constructs going forward
Date: Fri, 7 Aug 2020 14:09:24 -0500 [thread overview]
Message-ID: <CAPTJ0XF-PsKMCxU=UwWaWb+7-LxgV2KixkNNXyosW5UbnVF1-A@mail.gmail.com> (raw)
In-Reply-To: <33412819-8a5e-0c7f-7cfb-f3d127dc2242@linaro.org>
On Fri, Aug 7, 2020 at 9:06 AM Luis Machado via Gdb <gdb@sourceware.org> wrote:
>
> Hi,
>
> cc-ing the GCC mailing list, as we may want to use the same coding style
> for GDB and GCC.
>
> Yesterday I brought this topic up on IRC. I notice we started using more
> and more the "auto" keyword. In some cases, this is actually useful and
> makes the code a bit more compact. GDB has been using those more often,
> whereas GCC, for example, isn't using those too much.
>
> Looking at the coding standards for GCC
> (https://gcc.gnu.org/codingconventions.html), I don't see anything
> dictating best practices for "auto" use.
>
> I guess it is a consensus that "auto" is a good fit when dealing with
> iterators, lambda's and gnarly templates (but only when the type is
> already obvious from its use).
>
> There are other situations where "auto" may make things a little more
> cryptic when one wants to figure out the types of the variables. One
> example of this is when you have a longer function, and you use "auto"
> in a variable that lives throughout the scope of the function. This
> means you'll need to go back to its declaration and try to figure out
> what type this particular variable has.
>
> Pedro has pointed out LLVM's coding standards for "auto", which we may
> or may not want to follow/adopt:
> https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable
>
> It sounds like a reasonable idea to me. Thoughts?
The LLVM guide seems pretty similar to what the Google C++ guide
*used* to say, which was basically "You can use auto for iterators and
when the type is explicit on the initializer, e.g. for auto* x = new
Foo()". I liked that rule.
(The new version says "Use it if it makes the code more readable" with
no detailed guidance, which makes me sad)
Christian
next prev parent reply other threads:[~2020-08-07 19:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-07 14:06 Luis Machado
2020-08-07 14:56 ` Joel Brobecker
2020-08-07 15:48 ` Jakub Jelinek
2020-08-07 18:21 ` Jonathan Wakely
2020-08-07 19:09 ` Christian Biesinger [this message]
2020-08-11 13:55 ` Nathan Sidwell
2020-08-11 15:48 ` Jonathan Wakely
2020-08-12 2:46 ` Liu Hao
2020-08-12 18:40 ` David Blaikie
2020-08-13 6:44 ` Liu Hao
2020-08-13 8:03 ` Jonathan Wakely
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='CAPTJ0XF-PsKMCxU=UwWaWb+7-LxgV2KixkNNXyosW5UbnVF1-A@mail.gmail.com' \
--to=cbiesinger@google.com \
--cc=gcc@gcc.gnu.org \
--cc=gdb@sourceware.org \
--cc=luis.machado@linaro.org \
--cc=palves@redhat.com \
--cc=simark@simark.ca \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).