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


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


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