On 06/25/2015 09:28 PM, 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. Perhaps one disappointing exception is mixed space/tabs indentation. It is often inconsistent (i.e. some parts use space-only indentation). That's rather annoying because changes in such line trigger warnings in the checker script. I hope that I'll find some free time to address this problem (I mean, I'll write a script which will fix indentation in the GCC source tree, but will only change the lines affected by a given patch. So that we will have not just check_GNU_style, but also a kind of fix_GNU_style :) ). Of course the "ideal" solution would be to rewrite the whole repository (will full history), but that would break many things like MD5 sums of released versions and commit hashes in GIT mirror :(.
> (2) Is there supposed to be a space before a template parameter list? > I.e. is it: > > foo<bar> > > or: > > foo <bar> > > ? Both are widely used. There is a wiki page about coding conventions https://gcc.gnu.org/wiki/CppConventions and it mentions that the latter form should be used, but for some reason that rule did not get into official guide. > If this message does generate any discussion, I'm happy to write up > the result in the coding conventions and try to make the code base > consistent with it. My personal wishlist w.r.t. clarifications in coding conventions. I would be glad if someone explained this at least briefly, I could then document it and submit a patch for web site: 1. GCC has some common naming conventions. For example there are macros and functions ending with "_P" (or "_p"), they check for some property of their arguments (and my guess is that "p" stands for "predicate", but I still don't know for sure). There is also an "_r" suffix, which is used in callbacks for various traversals (reentrant? recursive?), foo/foo_1 pairs (wrappermain logic?). It would be nice to know the correct and intended use of such suffixes/prefixes/etc. 2. Is this C legacy or a convention: typedef struct some_name { ... } some_name_t; 3. Provided that we have a definition of "struct other_name", which is correct: "void foo (struct other_name *)" or "void foo (other_name *)"? 4. "int" is the universal type for induction variables and lots of other stuff in GCC. Isn't it better to use "unsigned" where semantics does not imply negative values? 5. In general: which is better: to support consistency with surrounding code or to use the new conventions? Particularly, the rule about declaring variables at the place of first use (in a function where all other variables are declared in the beginning)? P.S. Sorry in advance for continuing a bikeshed discussion :). -- Regards, Mikhail Maltsev
