Re: [cxx-conversion] New Hash Table (issue6244048)

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

On Fri, May 25, 2012 at 4:16 PM, Lawrence Crowl <crowl@google.com> wrote:
> On 5/25/12, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Fri, May 25, 2012 at 10:15:54AM -0400, Diego Novillo wrote:
>> > Lawrence, Ian and Gaby have been working on the proposed coding
>> > guidelines for C++ (http://gcc.gnu.org/wiki/CppConventions).
>>
>> That page is quite inconsistent. ?E.g. it first talks about
>> retaining space before ( (which I really hope will be retained,
>> it makes code more readable), but in the example it doesn't
>> bother with it. ?And the long line example is horribly ugly,
>> ending line with ( ? ?That ( should surely go on the next line
>> after the few spaces. ?It should list also examples of when the
>> first parameter isn't too long, but there are too many parameters
>> and so some wrapping is needed, etc.
>
> We will clean the page.
>
> There are technical guidelines that we can, and I think should,
> apply to the coding convention. ?In particular, I believe any coding
> convention should be consistent with the grammar of the language.

The problem with this is that it assumes that the grammar
is  a logical expression of the ideas and ideas of the language.
When that is the case, that is fine.  For C++ in particular, that is
not the case.  We have gone to extra length to fit ideas
and ideals into something that has grown barnacles and then
patch over those deficiencies by telling/teaching people to
write in certain ways.  The examples you gave below are great
and in some sense illustrate what the C++ would have liked to
happen (the ideas and ideals) as opposed to the gritty and
unsavory details of the horror that is the C++ grammar.  While
we should pay attention, I think it would be a mistake to set
coding conventions that mirror the horrors of the C++ grammar.

> Both the GNU style and the C++ Standard style break that guideline
> in different respects. ?For example, consider the following GNU code.
>
> ? ?int *p = *foo (3);
>
> Here, the convention implies that foo binds more tightly to the *
> than it does to the (. ?This implication is false.
>
> Now consider the C++ Standard equivalent.
>
> ? ?int* p = *foo(3);
>
> It fixes the binding of foo, but implies that * is syntactically
> closer to int than it is to p. ?That implication is false.
>
> Now consider a form that is consistent with the actual grammar of
> the language:
>
> ? ?int *p = *foo(3);
>
> Here there is no implication that foo binds more closely to either
> the * or the (, so the form is consistent with the grammar.

C++ standard thinks of "*" binding to "int" because it puts emphasis
on types -- and one of selling points of moving to C++ is that by
exploiting the static typing we would eliminate bugs and runtime
checks that are there only there because we could not get enough
static assurances and be sufficiently expressive and elegant
with the current implementation language.  Consequently, I think
we should retain the binding suggested by the C++ standard.
I realize that the existing GNU C convention says the opposite -- but
then it is written for C.

>
> We can go further and have the spacing reinforce the grammar, but
> lines will get longer.
>
> --
> Lawrence Crowl