* Re: Coding style for C++ constructs going forward
2020-08-07 14:06 Coding style for C++ constructs going forward Luis Machado
@ 2020-08-07 14:56 ` Joel Brobecker
2020-08-07 15:48 ` Jakub Jelinek
2020-08-07 18:21 ` Jonathan Wakely
` (2 subsequent siblings)
3 siblings, 1 reply; 11+ messages in thread
From: Joel Brobecker @ 2020-08-07 14:56 UTC (permalink / raw)
To: Luis Machado via Gcc; +Cc: gdb, Pedro Alves, Simon Marchi
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Coding style for C++ constructs going forward
2020-08-07 14:06 Coding style for C++ constructs going forward Luis Machado
2020-08-07 14:56 ` Joel Brobecker
@ 2020-08-07 18:21 ` Jonathan Wakely
2020-08-07 19:09 ` Christian Biesinger
2020-08-11 13:55 ` Nathan Sidwell
3 siblings, 0 replies; 11+ messages in thread
From: Jonathan Wakely @ 2020-08-07 18:21 UTC (permalink / raw)
To: Luis Machado; +Cc: gdb, gcc Mailing List, Pedro Alves, Simon Marchi
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)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Coding style for C++ constructs going forward
2020-08-07 14:06 Coding style for C++ constructs going forward Luis Machado
2020-08-07 14:56 ` Joel Brobecker
2020-08-07 18:21 ` Jonathan Wakely
@ 2020-08-07 19:09 ` Christian Biesinger
2020-08-11 13:55 ` Nathan Sidwell
3 siblings, 0 replies; 11+ messages in thread
From: Christian Biesinger @ 2020-08-07 19:09 UTC (permalink / raw)
To: Luis Machado; +Cc: gdb, gcc Mailing List, Pedro Alves, Simon Marchi
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Coding style for C++ constructs going forward
2020-08-07 14:06 Coding style for C++ constructs going forward Luis Machado
` (2 preceding siblings ...)
2020-08-07 19:09 ` Christian Biesinger
@ 2020-08-11 13:55 ` Nathan Sidwell
2020-08-11 15:48 ` Jonathan Wakely
2020-08-12 2:46 ` Liu Hao
3 siblings, 2 replies; 11+ messages in thread
From: Nathan Sidwell @ 2020-08-11 13:55 UTC (permalink / raw)
To: Luis Machado, gdb, gcc Mailing List, Pedro Alves, Simon Marchi
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Coding style for C++ constructs going forward
2020-08-11 13:55 ` Nathan Sidwell
@ 2020-08-11 15:48 ` Jonathan Wakely
2020-08-12 2:46 ` Liu Hao
1 sibling, 0 replies; 11+ messages in thread
From: Jonathan Wakely @ 2020-08-11 15:48 UTC (permalink / raw)
To: Nathan Sidwell
Cc: Luis Machado, gdb, gcc Mailing List, Pedro Alves, Simon Marchi
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()))
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Coding style for C++ constructs going forward
2020-08-11 13:55 ` Nathan Sidwell
2020-08-11 15:48 ` Jonathan Wakely
@ 2020-08-12 2:46 ` Liu Hao
2020-08-12 18:40 ` David Blaikie
1 sibling, 1 reply; 11+ messages in thread
From: Liu Hao @ 2020-08-12 2:46 UTC (permalink / raw)
To: Nathan Sidwell, Luis Machado, gdb, gcc Mailing List, Pedro Alves,
Simon Marchi
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Coding style for C++ constructs going forward
2020-08-12 2:46 ` Liu Hao
@ 2020-08-12 18:40 ` David Blaikie
2020-08-13 6:44 ` Liu Hao
0 siblings, 1 reply; 11+ messages in thread
From: David Blaikie @ 2020-08-12 18:40 UTC (permalink / raw)
To: Liu Hao
Cc: Nathan Sidwell, Luis Machado, gdb, gcc Mailing List, Pedro Alves,
Simon Marchi
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
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Coding style for C++ constructs going forward
2020-08-12 18:40 ` David Blaikie
@ 2020-08-13 6:44 ` Liu Hao
2020-08-13 8:03 ` Jonathan Wakely
0 siblings, 1 reply; 11+ messages in thread
From: Liu Hao @ 2020-08-13 6:44 UTC (permalink / raw)
To: David Blaikie
Cc: Nathan Sidwell, Luis Machado, gdb, gcc Mailing List, Pedro Alves,
Simon Marchi
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Coding style for C++ constructs going forward
2020-08-13 6:44 ` Liu Hao
@ 2020-08-13 8:03 ` Jonathan Wakely
0 siblings, 0 replies; 11+ messages in thread
From: Jonathan Wakely @ 2020-08-13 8:03 UTC (permalink / raw)
To: Liu Hao
Cc: David Blaikie, gcc Mailing List, gdb, Pedro Alves, Simon Marchi,
Nathan Sidwell
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.
^ permalink raw reply [flat|nested] 11+ messages in thread