On 09/26/2013 08:15 AM, Michael Matz wrote:
Hi,
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):
do.this ();
give.that()->flag;
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
method calls).
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.
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.
jeff
