Coding style for C++ constructs going forward

Coding style for C++ constructs going forward

[Luis Machado]

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.

Re: Coding style for C++ constructs going forward

[Joel Brobecker]

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

Re: Coding style for C++ constructs going forward

[Jakub Jelinek]

On Fri, Aug 07, 2020 at 07:56:03AM -0700, Joel Brobecker wrote:
> > 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

Also see the
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545829.html
thread on gcc-patches, including subject
'Describe coding conventions surrounding "auto"'
later in the thread.

	Jakub

Re: Coding style for C++ constructs going forward

[Jonathan Wakely]

On Fri, 7 Aug 2020 at 15:08, Luis Machado via Gcc <gcc@gcc.gnu.org> 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)

Re: Coding style for C++ constructs going forward

[Christian Biesinger]

On Fri, Aug 7, 2020 at 9:06 AM Luis Machado via Gdb <gdb@sourceware.org> 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?

The LLVM guide seems pretty similar to what the Google C++ guide
*used* to say, which was basically "You can use auto for iterators and
when the type is explicit on the initializer, e.g. for auto* x = new
Foo()". I liked that rule.

(The new version says "Use it if it makes the code more readable" with
no detailed guidance, which makes me sad)

Christian

Re: Coding style for C++ constructs going forward

[Nathan Sidwell]

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

Re: Coding style for C++ constructs going forward

[Jonathan Wakely]

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()))

Re: Coding style for C++ constructs going forward

[Liu Hao]

[-- Attachment #1.1: Type: text/plain, Size: 764 bytes --]

在 2020/8/11 下午9:55, Nathan Sidwell 写道:
> 
> 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'.
> 
> 

Personally I dislike this syntax. Pointers are objects, and `auto foo = expr;` should suffice. What if the type of `expr` is
`unique_ptr<T>` or `optional<T>`? The ptr-operator just can't exist there. So why the differentiation?

`auto& foo = ...` and `const auto& foo = ...` are necessary to indicate that the entity being declared is a reference (and
is not an object), while `auto*` doesn't make much sense, as I discourage plain pointers in my projects.



-- 
Best regards,
LH_Mouse


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Coding style for C++ constructs going forward

[David Blaikie]

On Tue, Aug 11, 2020 at 7:49 PM Liu Hao via Gdb <gdb@sourceware.org> wrote:
>
> 在 2020/8/11 下午9:55, Nathan Sidwell 写道:
> >
> > 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'.
> >
> >
>
> Personally I dislike this syntax. Pointers are objects, and `auto foo = expr;` should suffice. What if the type of `expr` is
> `unique_ptr<T>` or `optional<T>`? The ptr-operator just can't exist there. So why the differentiation?
>
> `auto& foo = ...` and `const auto& foo = ...` are necessary to indicate that the entity being declared is a reference (and
> is not an object), while `auto*` doesn't make much sense, as I discourage plain pointers in my projects.

Then use of `auto*` would make it easier for you to spot use of plain
pointers in your projects & scrutinize them further?

>
>
>
> --
> Best regards,
> LH_Mouse
>

Re: Coding style for C++ constructs going forward

[Liu Hao]

[-- Attachment #1.1: Type: text/plain, Size: 491 bytes --]

在 2020/8/13 上午2:40, David Blaikie 写道:
> 
> Then use of `auto*` would make it easier for you to spot use of plain
> pointers in your projects & scrutinize them further?
> 

My point is that `auto*` conveys no more information than `auto`. The absence of `*` does not imply the object (pointer)
being declared can never be null (apologies for this triple negation), so it complexifies coding rules and probably should
not be used at all.


-- 
Best regards,
LH_Mouse


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Coding style for C++ constructs going forward

[Jonathan Wakely]

On Thu, 13 Aug 2020 at 07:46, Liu Hao via Gcc <gcc@gcc.gnu.org> wrote:
>
> 在 2020/8/13 上午2:40, David Blaikie 写道:
> >
> > Then use of `auto*` would make it easier for you to spot use of plain
> > pointers in your projects & scrutinize them further?
> >
>
> My point is that `auto*` conveys no more information than `auto`. The absence of `*` does not imply the object (pointer)
> being declared can never be null (apologies for this triple negation), so it complexifies coding rules and probably should
> not be used at all.

I am not aware of any significant downsides to it. You are of course
welcome to ban raw pointers from your own code, but that's not going
to happen for GCC any time soon, so maybe different rules should
apply.