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: Jeff Law <law at redhat dot com>
- Cc: Michael Matz <matz at suse dot de>, Paolo Carlini <paolo dot carlini at oracle dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 28 Sep 2013 10:31:38 -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> <524511A4 dot 4030808 at redhat dot com>
On 09/27/2013 01:03 AM, Jeff Law wrote:
I don't like the more functional interface... I thought the suggestion
might be a little tongue in cheek, but wasn't sure :-) I can't imagine
the number of templates that would introduce... and the impact on
compile/link time would probably not be trivial.
On 09/26/2013 08:15 AM, Michael Matz wrote:
Should we consider banning dereferencing the result of a method call
and instead prefer to use a more functional interface such as Jakub
has suggested, or have the result of the method call put into a
temporary and dereference the temporary.
On Wed, 25 Sep 2013, Jeff Law wrote:
Yea. I actually reviewed the libstdc++ guidelines to see where they
Which wouldn't be so weird: in the libstdc++-v3 code we do it all
I was going to bring it up at some point too. My preference is
strongly to simply eliminate the space on methods...
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_
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
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
I considered suggesting the latter. I wouldn't be a huge fan of the
unnecessary temporaries, but they may be better than the horrid
foo.last()->argh()->e->src or whatever.
Stuffing the result into a temporary does have one advantage, it
encourages us to CSE across the method calls in cases where the
compiler might not be able to do so. Of course, being humans, we'll
probably mess it up.
temps would be OK with me, but there are a couple of concerns.
- I'd want to be able to declare the temps at the point of use, not
the top of the function. this would actually help with clarity I think.
Not sure what the current coding standard says about that.
- the compiler better do an awesome job of sharing stack space for
user variables in a function... I wouldn't want to blow up the stack
with a bazillion unrelatd temps each wit their own location.
My example in this form would look something like:
int unsignedsrcp = ptrvar.type().type().type_unsigned();
GimpleType t1 = ptrvar.type ();
GimpleType t2 = t1.type ();
int unsignedsrcp = t2.type.unsigned ();
And yes, we'll probably introduce the odd human CSE error.. hopefully
the test suite will catch them :-)
I think I still prefer matz's suggestion, but I could be on board with
this one too. some expressions are crazy complicated