From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rock.gnat.com (rock.gnat.com [IPv6:2620:20:4000:0:a9e:1ff:fe9b:1d1]) by sourceware.org (Postfix) with ESMTP id 45AE13851C35 for ; Fri, 7 Aug 2020 14:56:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 45AE13851C35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=brobecker@adacore.com Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id EB1E811708A; Fri, 7 Aug 2020 10:56:06 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at gnat.com Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JoL13eAeux8j; Fri, 7 Aug 2020 10:56:06 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 38525117089; Fri, 7 Aug 2020 10:56:06 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id CE0E582C47; Fri, 7 Aug 2020 07:56:03 -0700 (PDT) Date: Fri, 7 Aug 2020 07:56:03 -0700 From: Joel Brobecker To: Luis Machado via Gcc Cc: "gdb@sourceware.org" , Pedro Alves , Simon Marchi Subject: Re: Coding style for C++ constructs going forward Message-ID: <20200807145603.GN28417@adacore.com> References: <33412819-8a5e-0c7f-7cfb-f3d127dc2242@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33412819-8a5e-0c7f-7cfb-f3d127dc2242@linaro.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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: Fri, 07 Aug 2020 14:56:09 -0000 Hi Luis, > 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? Thanks for the pointer to LLVM's CS guideline. FWIW, it's explaining quite nicely what I had in the back of my mind. I think it would be a good starting point, at least for discussing whathever guidelines we might want to adopt in GDB. > Are there other C++ constructs people think would benefit from a more formal > style guideline? As we move to newer C++ standards over time, it is more > likely we will start using newer constructs, and some of those may make the > code potentially less readable. -- Joel