From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) by sourceware.org (Postfix) with ESMTPS id B7D6F3857C43 for ; Fri, 7 Aug 2020 14:06:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B7D6F3857C43 Received: by mail-qt1-x835.google.com with SMTP id d27so1330266qtg.4 for ; Fri, 07 Aug 2020 07:06:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=YmlZcMVP9yOD4lqIL2Dabw6HjTruyuAqEs9XuHsCATk=; b=EVP6lYD8hyZpvy18ibKi/MFQDpX5ZUXq2e5EGDDgmA4QFjaER4RrktpjsOYOWC4j+f yVgRC44puFke7CcPJY+s/Odcpbh7xqDYTV6kNBj4t0gdpuTaeyBlhgE7gTqQuyueDABr ToSPbxHgYYN8cYtBsn6asIkV/b+u+GgUgRR53alw65pcLgjq2UNvMJUAA4hNUvudGDfJ 3Z4rPypDcd/80iXqkuRxirnkk9wryGQqKOcR6NkRPy6TgwXpnnP9D6IsL321UbPcQoTj OszEoDGMzbeAFKw+1q6A2xbEtqNUeG9mkoX0uI4j9bDgHA2zqNAGqD0TCoU9IjAkmiGp tpfA== X-Gm-Message-State: AOAM533e30Q9nSwDQRYu/7oHHSzu5QDacrIuq8HeoXPH8Ay18rye4pbd ExwKHvjvuAsLQWgj7944L605Sw== X-Google-Smtp-Source: ABdhPJz37qOhNgnOmWrHDzbPEV/mn0f2Bz/AMYQTONsk589OWAio69hyrvTPYz67QYxh9ZuvupnfRA== X-Received: by 2002:aed:38c3:: with SMTP id k61mr14246355qte.11.1596809179205; Fri, 07 Aug 2020 07:06:19 -0700 (PDT) Received: from ?IPv6:2804:7f0:8283:6f2c:b77d:47b2:730b:373? ([2804:7f0:8283:6f2c:b77d:47b2:730b:373]) by smtp.gmail.com with ESMTPSA id f31sm7987166qte.35.2020.08.07.07.06.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 Aug 2020 07:06:18 -0700 (PDT) To: "gdb@sourceware.org" , gcc Mailing List , Pedro Alves , Simon Marchi From: Luis Machado Subject: Coding style for C++ constructs going forward Message-ID: <33412819-8a5e-0c7f-7cfb-f3d127dc2242@linaro.org> Date: Fri, 7 Aug 2020 11:06:13 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=unavailable 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:06:21 -0000 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? 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.