Coding style for C++ constructs going forward

Nathan Sidwell nathan@acm.org
Tue Aug 11 13:55:10 GMT 2020


On 8/7/20 10:06 AM, 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).
> 
> 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?

I agree, it's the way I use auto.  I particularly like the
    auto *foo = expr;
idiom, when you're getting a pointer, but the type of the pointee is 
clear.  It informs how you use 'foo'.


> 
> 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.


-- 
Nathan Sidwell


More information about the Gdb mailing list