This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [05/13] Add nofree_ptr_hash
- From: Richard Sandiford <richard dot sandiford at arm dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, "gcc-patches\ at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 25 Jun 2015 18:33:47 +0100
- Subject: Re: [05/13] Add nofree_ptr_hash
- Authentication-results: sourceware.org; auth=none
- References: <87fv5s2gej dot fsf at e105548-lin dot cambridge dot arm dot com> <87twu8118n dot fsf at e105548-lin dot cambridge dot arm dot com> <5589D173 dot 8050508 at redhat dot com> <87ioadsefa dot fsf at e105548-lin dot cambridge dot arm dot com> <558B732B dot 4040700 at redhat dot com> <CAFiYyc2b1Z+mrgf1+eD_sxUdH0KZdh8kg1hz0NL1WhuLvb=nJw at mail dot gmail dot com> <558C2CEE dot 2010803 at redhat dot com>
Jeff Law <law@redhat.com> writes:
> On 06/25/2015 03:49 AM, Richard Biener wrote:
>> On Thu, Jun 25, 2015 at 5:19 AM, Jeff Law <law@redhat.com> wrote:
>>> On 06/24/2015 02:23 AM, Richard Sandiford wrote:
>>>>
>>>> Jeff Law <law@redhat.com> writes:
>>>>>
>>>>> So I'm holding off on approving this one pending further discussion of
>>>>> the use of multiple inheritance for nofree_ptr_hash.
>>>>
>>>>
>>>> I thought that might be controversial. :-) My two main defences are:
>>>>
>>>> 1) This is multiple inheritance of traits classes, which all just have
>>>> static member functions, rather than multiple inheritance of data-
>>>> carrying classes. It's really just a union of two separate groups
>>>> of functions.
>>>
>>> As I was thinking about this during review I almost convinced myself that
>>> multiple inheritance from traits classes ought to be acceptable.
>>>
>>> As you state, they don't carry data and we're just getting a union of their
>>> functions. One could probably even argue that traits classes by their
>>> nature are designed to be composed with other traits and classes.
>>>
>>> I'm (obviously) not as well versed in this stuff as I ought to be, hence my
>>> conservatism. It'd be real helpful if folks with more real world experience
>>> in this space could chime in on the pros/cons if this approach.
>>>
>>> If we do go forward, ISTM updating our coding conventions to codify this
>>> exception to the "avoid MI" would be wise. And my inclination is to go
>>> forward, but let's give other folks a chance to chime in.
>>
>> Yes, I think this is ok.
> Works for me. Richard S., as a follow-up can you update the coding
> conventions, which I think it maintained in the ancient CVS repo for the
> web pages (ping Gerald if you're unfamiliar with it).
OK, sounds good. How does this look?
Thanks,
Richard
Index: htdocs/codingconventions.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v
retrieving revision 1.71
diff -u -r1.71 codingconventions.html
--- htdocs/codingconventions.html 9 Jul 2014 00:03:05 -0000 1.71
+++ htdocs/codingconventions.html 25 Jun 2015 17:31:39 -0000
@@ -888,6 +888,9 @@
On the rare occasion that using mulitple inheritance is indeed useful,
prepare design rationales in advance,
and take special care to make documentation of the entire hierarchy clear.
+(In particular, multiple inheritance can be an acceptable way of combining
+"traits"-style classes that only contain static member functions.
+Its use with data-carrying classes is more problematic.)
</p>
<p>