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. > Furthermore, we've used similar idioms in the past when moving objects > from the global namespace into structures (the x_ prefixing you'll find > in various structures). Yes, but that is usually done to not confuse ourself when there are accessor macros of the same name as the accessed member/variable, i.e. when we want to make really sure that we never, from no code, access the variable itself. I.e. the uglification serves the purpose of avoiding access to that name. That's not the case with these class members. They are quite clearly accessed in all the member functions, and they are intended to be accessed from them. So they should have no uglified name. > You really should have chimed in before now. Yes I should have, but better late than never. As of now it's no trend of uglification yet, the only preexisting cases of the same type (uglified class member names) are the pass manager and bit_field_mode_iterator, both fairly recent. The other case (vec.h) should have been changed to non-ugly names when it was converted to classes. In any case we should not introduce more of these. > > 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!?) > > 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_++; 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. Ciao, Michael.