From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) by sourceware.org (Postfix) with ESMTPS id 01D40388C01E for ; Fri, 7 Aug 2020 18:22:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 01D40388C01E Received: by mail-io1-xd31.google.com with SMTP id s189so2843519iod.2 for ; Fri, 07 Aug 2020 11:22:01 -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; bh=4bciabYIWX7hx4sJ8/bEzsMrXjyqgJ+szWQuUFWrwkg=; b=UsUy51lHvlr3T58lKwlJ+b0YFFJIzd5Zp6dCYpgLquhKKGWWh+9FlSJUjwaiZx8rfb aWevV/23lVphuPe760j6Qvh6NdJ8qW6d6ky3FAClID/xBlLZC7yWk2wz4YhJGTA2pxlf SPyZD3lK+pMbCASITNLhYrBxN6E4Ho/WIfJKh+/l5o5qmjVrrsZqMmyixK0YFuNQ12ML sLJzUJydo3c7IsLEavid6O5MYksCxWO2htJTdH5674HsWzJuP1Yhv+Y3knzc39ul6oY8 3uIy7BbQwZ8N+M3vi+GUDrd9xfde8voJPZYQlqss1NUcxQsvYYEY68rqURs92tjYS6vb za1Q== X-Gm-Message-State: AOAM5300477c9dwcwCWkQCNa+fhAlqYGcDDmGguw1VHgeUWgWX58BqA6 KBzeQdC/UAUt88MNm7G//ZWRV63VBeYrjwGUGR4= X-Google-Smtp-Source: ABdhPJxuOaduTBoztgyyrkwFLBdnUo7t+fEjtMSGH0exzT6geSf8xAzn6/5/L44b97KniA8ffT7ycEHsS/EwAZMqICs= X-Received: by 2002:a6b:7e41:: with SMTP id k1mr5740539ioq.130.1596824521450; Fri, 07 Aug 2020 11:22:01 -0700 (PDT) MIME-Version: 1.0 References: <33412819-8a5e-0c7f-7cfb-f3d127dc2242@linaro.org> In-Reply-To: <33412819-8a5e-0c7f-7cfb-f3d127dc2242@linaro.org> From: Jonathan Wakely Date: Fri, 7 Aug 2020 19:21:49 +0100 Message-ID: Subject: Re: Coding style for C++ constructs going forward To: Luis Machado Cc: "gdb@sourceware.org" , gcc Mailing List , Pedro Alves , Simon Marchi Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, 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: Fri, 07 Aug 2020 18:22:03 -0000 On Fri, 7 Aug 2020 at 15:08, Luis Machado via Gcc 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). GCC only moved to C++11 very recently, so it's unsurprising. > 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? It seems like common sense to me. "Almost always use auto" is a silly guideline. I can't stand seeing nonsense like: auto main() -> int { ... } > 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. I'm also not a fan of "always use {} for init" rules. There are times when using {} for initialization is necessary, or more convenient (e.g. it avoids ambiguities in the grammar that would need clunky workarounds to avoid otherwise) but that doesn't make it always better. On the other hand, I do like: - nullptr instead of NULL - constructors and assignment ops defined with = default - default member initializers i.e. struct X { void* p = nullptr; size_t num = 0; }; (especially useful in GCC code where leaving members uninitialized seems to be the norm)