This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] manage dom-walk_data initialization and finalization with constructors and destructors

On 09/18/2013 11:17 AM, Michael Matz wrote:

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?

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_);
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]