This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Trivial cleanup
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Michael Matz <matz at suse dot de>, Jeff Law <law at redhat dot com>, Paolo Carlini <paolo dot carlini at oracle dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 26 Sep 2013 17:52:37 -0400
- Subject: Re: [PATCH] Trivial cleanup
- Authentication-results: sourceware.org; auth=none
- References: <5243025E dot 8050101 at redhat dot com> <52430544 dot 8030005 at redhat dot com> <524305C3 dot 3050003 at oracle dot com> <5243086D dot 3030806 at redhat dot com> <alpine dot LNX dot 2 dot 00 dot 1309261605360 dot 11100 at wotan dot suse dot de> <CAFiYyc3BmrOePBsNHQbt3XNJrRDjpaUEy5ZHaaKVX9jsXwwAqQ at mail dot gmail dot com>
On 09/26/2013 10:21 AM, Richard Biener wrote:
On Thu, Sep 26, 2013 at 4:15 PM, Michael Matz <email@example.com> wrote:
On Wed, 25 Sep 2013, Jeff Law wrote:
I was going to bring it up at some point too. My preference is
strongly to simply eliminate the space on methods...
Which wouldn't be so weird: in the libstdc++-v3 code we do it all the time.
Yea. I actually reviewed the libstdc++ guidelines to see where they differed
from GNU's C guidelines.
I'm strongly in favor of dropping the horizontal whitespace between the
method name and its open paren when the result is then dereferenced.
ie foo.last()->e rather than foo.last ()->e.
I'd prefer to not write in this style at all, like Jakub. If we must
absolutely have it, then I agree that the space before _empty_ parentheses
are ugly if followed by references. I.e. I'd like to see spaces before
parens as is customary, except in one case: empty parens in the middle of
expressions (which don't happen very often right now in GCC, and hence
wouldn't introduce a coding style confusion):
get.list (one)->clear ();
I'd prefer to not have further references to return values be applied,
though (as in, the parentheses should be the end of statement), which
would avoid the topic (at the expensive of having to invent names for
those temporaries, or to write trivial wrapper methods contracting several
Seconded, even give.that()->flag; is ugly.
I don't find it ugly :-)
so my example would end up being
int unsignedsrcp = ptrvar.type().type().type_unsigned (); ?
I can live with this suggestion... its the sequence of 2 or 3 or 4
empty parens with spaces that I really found distasteful.