public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: Liu Hao <lh_mouse@126.com>
Cc: David Blaikie <dblaikie@gmail.com>,
	gcc Mailing List <gcc@gcc.gnu.org>,
	 "gdb@sourceware.org" <gdb@sourceware.org>,
	Pedro Alves <palves@redhat.com>, Simon Marchi <simark@simark.ca>,
	Nathan Sidwell <nathan@acm.org>
Subject: Re: Coding style for C++ constructs going forward
Date: Thu, 13 Aug 2020 09:03:33 +0100	[thread overview]
Message-ID: <CAH6eHdQ4DF61x4smg=t8rOCVGH4ytcoKyovr6_FUjfu3kqkPJg@mail.gmail.com> (raw)
In-Reply-To: <0c76a6e8-6c08-1f10-e308-5b09c18ff3bc@126.com>

On Thu, 13 Aug 2020 at 07:46, Liu Hao via Gcc <gcc@gcc.gnu.org> wrote:
>
> 在 2020/8/13 上午2:40, David Blaikie 写道:
> >
> > Then use of `auto*` would make it easier for you to spot use of plain
> > pointers in your projects & scrutinize them further?
> >
>
> My point is that `auto*` conveys no more information than `auto`. The absence of `*` does not imply the object (pointer)
> being declared can never be null (apologies for this triple negation), so it complexifies coding rules and probably should
> not be used at all.

I am not aware of any significant downsides to it. You are of course
welcome to ban raw pointers from your own code, but that's not going
to happen for GCC any time soon, so maybe different rules should
apply.

      reply	other threads:[~2020-08-13  8:03 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
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 [this message]

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='CAH6eHdQ4DF61x4smg=t8rOCVGH4ytcoKyovr6_FUjfu3kqkPJg@mail.gmail.com' \
    --to=jwakely.gcc@gmail.com \
    --cc=dblaikie@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb@sourceware.org \
    --cc=lh_mouse@126.com \
    --cc=nathan@acm.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).