This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] manage dom-walk_data initialization and finalization with constructors and destructors
- From: Michael Matz <matz at suse dot de>
- To: Jeff Law <law at redhat dot com>
- Cc: Trevor Saunders <tsaunders at mozilla dot com>, Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 19 Sep 2013 15:23:21 +0200 (CEST)
- Subject: Re: [PATCH] manage dom-walk_data initialization and finalization with constructors and destructors
- Authentication-results: sourceware.org; auth=none
- References: <1378264562-30803-1-git-send-email-tsaunders at mozilla dot com> <CAFiYyc2WMqt7b=riv_3+LUDQ=+OjycgEqK+L8afjPcaVzU9Wag at mail dot gmail dot com> <20130904145911 dot GC17620 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com> <522759C8 dot 5040802 at redhat dot com> <20130911000350 dot GA28492 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com> <52389CB1 dot 60504 at redhat dot com> <5239126A dot 6010702 at redhat dot com> <alpine dot LNX dot 2 dot 00 dot 1309181640400 dot 9949 at wotan dot suse dot de> <5239D985 dot 4080205 at redhat dot com> <alpine dot LNX dot 2 dot 00 dot 1309181849550 dot 9949 at wotan dot suse dot de> <523A7C15 dot 60508 at redhat dot com>
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.