This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ coding style inconsistencies


Hi,

On Thu, Jun 25, 2015 at 04:59:51PM -0400, David Malcolm wrote:
> On Thu, 2015-06-25 at 19:28 +0100, Richard Sandiford wrote:
> > 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++".
> 
> [...snip...]
> 
> If we're bike-shedding (sorry, I'm waiting for a bootstrap), do we have
> a coding standard around the layout of member initialization in
> constructors?

Yes, https://gcc.gnu.org/codingconventions.html#Member_Form

> 
> i.e. should it be:
> 
> foo::foo (int x, int y) :
>   m_x (x),
>   m_y (y)
> {
> }
> 
> vs
> 
> foo::foo (int x, int y)
>   : m_x (x),
>     m_y (y)
> {
> }

according to the document, the semicolon should be on the first column
if all initializers do not fit on one line with the definition.  Emacs
gnu-style indentation does not do that and produces your second case
above, which, according to some simple grepping, is also greatly
prevails in the codebase now.  So perhaps we should change the rule?

> 
> (how much indentation?)
> 
> https://gcc.gnu.org/wiki/CppConventions

I'd be wary of citing and using this document, IIRC it sometimes
contradicts the official one and was meant as a basis for discussion
when we were discussing whether to switch to gcc in the first place.

Martin

> has an example suggesting the
> latter, but puts both on the same line and then puts the empty body on
> one line, and doesn't have the space between the name and the
> open-paren, like this:
> 
> foo::foo(int x, int y)
>   : m_x(x), m_y(y)
> { }
> 
> though actually, it's inline in the class decl, akin to:
> 
> class foo {
>   foo(int x, int y)
>     : m_x(x), m_y(y)
>   { }
> 
> 
> vs the one-liner for this simple case:
> 
> foo::foo (int x, int y) : m_x (x), m_y (y) {}
> 
> 
> fwiw GNU indent turns this into:
> 
> foo::foo (int x, int y):
> m_x (x),
> m_y (y)
> {
> }
> 
> which I think is ugly (I suspect this is a case of "indent" not handling
> C++).
> 
> fwiw I don't have a preference between either of the top two styles, and
> Emacs seems to cope with both.  I like having the option of doing it all
> on one line where it's simple enough.
> 
> Dave
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]