Hi, On Wed, 18 Sep 2013, Jeff Law wrote:
> > 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. As I said, yes; I also said those were pre-existing from the C times already, so they don't support the new c++ guidelines. I do have several issues with the style guidelines, and yes, it's my fault for not having gone through the pains of trying to fight off those things last year :-/ > It's well established at this point I wouldn't call two recent examples well established, but well. > I don't see anything in Trevor's work that requires jumping through > hoops. Me neither, from that perspective it's okay. It's merely that I doubt the value of any syntactic privatization like it's implemented in C++, you can #define it away, hence the compiler can't make use of that information for code generation, and the cognitive value for the developer ("hey I shouldn't look at this member from outside") is dubious, as that probably is a general rule, no direct data member access from non-members (although I have problems with that too). And I think the fact that Trevor made one data member non-private to access it from a non-member function (move_computations_dom_walker::todo) just underlines my point: private is useless and gets in the way. > > 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. this->x. >From the wiki it seems that was dicussed (on the wiki, not the mailing list) and rejected by Lawrence on the grounds of indroducing too long lines. I agree with that, but I don't agree that therefore members should be named foo_. > Given it's recommended by our C++ guidelines which were discussed at > length, I'm going to explicitly NAK your patch. Hmmkay. > FWIW, I have worked on large C++ codebases Me too. > that were a free-for-all and found them *amazingly* painful. I don't think any of my mails about style can be interpreted as advocating free-for-all. > 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. Funnily it's the small things that weren't much discussed (probably because they are deemed not very important) in the convention that give me a hard time, nits such as these syntactic uglifications. The larger things indeed mostly are okayish. Ciao, Michael.