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: Ian Lance Taylor <iant at google dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: Jeff Law <law at redhat dot com>, 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: Wed, 18 Sep 2013 15:00:42 -0700
- 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>
On Wed, Sep 18, 2013 at 10:17 AM, Michael Matz <matz@suse.de> wrote:
>
>> > 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 accidentally sent the e-mail in HTML mode, and it bounced. I didn't
think it was important enough to resend.
But I wouldn't go so far as to say that we should never use private
members, just that I think it's better to use public members than to
contort the code to force them to be private.
In any case I do think that any discussion of this area should be with
regard to suggested changes to the coding conventions at
http://gcc.gnu.org/codingconventions.html . Those conventions do say
"Prefer to make data members private" and "When structs and/or classes
have member functions, prefer to name data members with a trailing
underscore."
Ian