Re: Coding style for C++ constructs going forward

[Jonathan Wakely <jwakely.gcc@gmail.com>]

On Tue, 11 Aug 2020 at 14:56, Nathan Sidwell <nathan@acm.org> wrote:
>
> 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'.

Yes, great suggestion. I use that in libstdc++ too, e.g.

include/bits/shared_ptr.h:      if (auto* __p = dynamic_cast<typename
_Sp::element_type*>(__r.get()))