On 09/18/2013 11:17 AM, Michael Matz wrote:
Hi,
On Wed, 18 Sep 2013, Jeff Law wrote:
On 09/18/2013 10:24 AM, Michael Matz wrote:
I'm irritated by the member name uglification (e.g. equiv_stack_ with
trailing underscore). I know that's a certain style to mark private
members, but I think it's a bad style (like prefixing variable names with
their type), and before it sets a precedent in GCCs c++ coding style I'd
like this to be changed, like in the below.
We're already using the trailing underscore idiom for private objects
moving into classes (see the pass class).
I know, and I don't like it there either.
Well, as Ian pointed out, it is in our recommended style guidelines and
you'll find uses in the vec class as well. It's well established at
this point and I see no compelling reason to go back unless you can
convince the project as a whole to change the C++ guidelines.
I'd also like us to not use member privatization in our classes, but
that's not in the patch, but if we could agree on that it would be nice.
Member privatization is quite natural. What specifically do you not like
about the practice?
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00302.html
That was conditional on "when we need to jump through hoops", but for
constistency it'd make sense to avoid it everywhere.
(I know that Ian agreed to that mail, but somehow the mailing list
archives don't have that!?)
I don't see anything in Trevor's work that requires jumping through
hoops. It's pretty simple stuff. And again, as Ian pointed out, our
established guidelines for C++ usage encourage this behaviour.
Regstrapped on x86-64-linux, okay?
Obviously any ChangeLog, formatting and such can go in. However, the
trailing underscore should stay given it's already established practice
and has several nice benefits.
What's the benefit of reading and writing such noisy lines? :
*out_mode = mode_;
mode_ = GET_MODE_WIDER_MODE (mode_);
count_++;
It makes it very clear to the reader that we're dealing with objects
that belong to a class instance rather than direct access to an auto or
static. That can be important.
The uglification merely makes code harder to write and read, it should be
used in cases where you _don't_ want developers to write such names.
I feel it makes it harder in some ways and easier in others.
Given it's recommended by our C++ guidelines which were discussed at
length, I'm going to explicitly NAK your patch. If you want to re-open
the guidelines for C++ usage, then that's fine with me and if we as a
project change the guidelines to disallow such things, then that will be
the time to remove the trailing underscores, private members, etc.
FWIW, I have worked on large C++ codebases that were a free-for-all and
found them *amazingly* painful. The restricted set allowed for GCC is
actually quite reasonable IMHO, particularly for projects where the main
body of code is evolving from a pure C base.
Jeff
