From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x142.google.com (mail-il1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) by sourceware.org (Postfix) with ESMTPS id 21EA53858D38 for ; Thu, 13 Aug 2020 08:03:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 21EA53858D38 Received: by mail-il1-x142.google.com with SMTP id z17so4809918ill.6 for ; Thu, 13 Aug 2020 01:03:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=82MGn2EVFCzN9Chw8LO7uACpOB3GUyXi8IHpNcWHkQM=; b=PjQtLkYZKWtsqoglEnWun9z6IXavzybToOMgSmno0xZH330JOSI6zPCzlWhccvsG5o BnBO4KM0CMKqJr/g4GYB4MAbiKG2Gx5TI7z+CzlymOTmQBN0lcY2gc3ehEcl1pjDFDze wXUtUKJi020q0+Jds0YBr8w7w0+pEhtCQin/so9gzep6/DEgyMdFNSYOG9w93O5cpio4 hslM8HHwjE1d+C47g65w9qm+qHQMB2MUb+jUTDHpFH4bfoP2O90r+2ccW9USU5uDKYZl K8FXKWhPzHlHLCjxXPoa0jplV1bmMcUbW6dJEf7hPjKDqwqToaO7mevoQ8+YL5TvxjP0 WW/Q== X-Gm-Message-State: AOAM532/wUjfspA5qkcttQ3lE2J8DLmM0Jtuw6W75Jxzi55Go2nwY8Yy 5ALiSQX1Gn+AjUOz61/POn9PTdfR1DnQsTL1sE0= X-Google-Smtp-Source: ABdhPJwltqcNs1xcu2cxD8DDp3/VAJiHlA4Lm58quHxDjmx8LhNwPYJ9w3+fO8lExVg9KGKGfHL4RnXy9QYhHz3uQU8= X-Received: by 2002:a92:414b:: with SMTP id o72mr3354736ila.59.1597305824613; Thu, 13 Aug 2020 01:03:44 -0700 (PDT) MIME-Version: 1.0 References: <33412819-8a5e-0c7f-7cfb-f3d127dc2242@linaro.org> <0c76a6e8-6c08-1f10-e308-5b09c18ff3bc@126.com> In-Reply-To: <0c76a6e8-6c08-1f10-e308-5b09c18ff3bc@126.com> From: Jonathan Wakely Date: Thu, 13 Aug 2020 09:03:33 +0100 Message-ID: Subject: Re: Coding style for C++ constructs going forward To: Liu Hao Cc: David Blaikie , gcc Mailing List , "gdb@sourceware.org" , Pedro Alves , Simon Marchi , Nathan Sidwell Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 08:03:46 -0000 On Thu, 13 Aug 2020 at 07:46, Liu Hao via Gcc wrote: > > =E5=9C=A8 2020/8/13 =E4=B8=8A=E5=8D=882:40, David Blaikie =E5=86=99=E9=81= =93: > > > > 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 abs= ence 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.