This is the mail archive of the
mailing list for the GCC project.
Re: C++ coding style inconsistencies
- From: Jeff Law <law at redhat dot com>
- To: gcc at gcc dot gnu dot org, rdsandiford at googlemail dot com
- Date: Thu, 25 Jun 2015 14:44:17 -0600
- Subject: Re: C++ coding style inconsistencies
- Authentication-results: sourceware.org; auth=none
- References: <87vbeblk0y dot fsf at googlemail dot com>
On 06/25/2015 12:28 PM, Richard Sandiford wrote:
I'd say let's go with the existing rule. I know that in-class
definitions are relatively common, particularly if they are trivial, so
do we want an exception for anything that fits on a single line?
Sorry in advance for inviting a bikeshed discussion, but while making
the hashing changes that I just committed, I noticed that the C++ification
has been done in a variety of different styles. I ended up having to follow
the "do what the surrounding code does" principle that some code bases have,
but to me that's always seemed like an admission of failure. One of the
strengths of the GCC code base was always that it was written in a very
consistent style. Regardless of what you think of that style (I personally
like it, but I know others don't at all), it was always easy to work on
a new area of the compiler without having to learn how the surrounding code
preferred to format things. It would be a shame if we lost that in the
rush to make everything "more C++".
The three main inconsistencies I saw were:
(1) Should inline member functions be implemented inside the class or outside
the class? If inside, should they be formatted like this:
or like this:
(both have been used).
The coding standard is pretty clear about this one:
Define all members outside the class definition. That is, there
are no function bodies or member initializers inside the class
But in-class definitions have become very common. Do we want
to revisit this? Or do we just need more awareness of what the
rule is supposed to be?
[Personally I like the rule. The danger with in-class definitions
is that it becomes very hard to see the interface at a glance.
It obviously makes things more verbose though.]
I'd go with whatever gnu-ident does with these things. I'd hate for us
to settle on a style that requires non-default behaviour from gnu-indent.
(2) Is there supposed to be a space before a template parameter list?
I.e. is it:
? Both are widely used.
The current coding conventions don't say explicitly, but all the
examples use the second style. It's also more in keeping with
convention for function parameters. On the other hand, it could
be argued that the space in:
foo <bar, frob>::thing
makes the binding confusing and looks silly compared to:
But there again, the second one might look like two unrelated
blobs at first glance.
(3) Do we allow non-const references to be passed and returned by
non-operator functions? Some review comments have pushed back
on that, but some uses have crept in.
[IMO non-const references are too easy to misread as normal
In all three cases, whether the answer is A or B is less important
than whether the answer is the same across the code base.
I could make an argument either way on this one...