Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

[Jeff Law <law@redhat.com>]

On 11/06/13 04:31, Richard Biener wrote:
> On Wed, Nov 6, 2013 at 12:02 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
>> On 11/06/2013 10:31 AM, Richard Biener wrote:
>>> We decided to move to C++.  As part of a later discussion we decided
>>> to go with a single general dynamic-casting style, mimicing the "real"
>>> C++ variant which is dynamic_cast < ... >.  Which resulted in
>>> is-a.h.
>>>
>>> So yes, we've decided to go C++ so we have to live with certain
>>> uglinesses of that decisions (and maybe over time those uglinesses
>>> will fade away and we get used to it and like it).
>>>
>>> Thus, there isn't another option besides using the is-a.h machinery
>>> and enabling and using RTTI.  Sticking to C for gimple doesn't seem
>>> to be consistent with the decision to move to C++.
>>>
>>> Oh, I'm not saying I'm a big fan of as_a / is_a or C++ in general
>>> as it plays out right now.  But well, we've had the discussion and
>>> had a decision.
>>
>> Maybe we need to revisit it? As one of those who were not in favour of
>> the C++ move, can I ask you guys to step back for a moment and think
>> about - what do all of these changes buy us, exactly? Imagine the state
>> at the end, where everything is converted and supposedly the temporary
>> ugliness is gone, what have we gained over the code as it is now?
>
> as_a gains us less runtime checking and more static type checking
> which is good.
Absolutely.

> That I agree to.  Instead of fixing the less than optimal separation / boundary
> between frontends and the middle-end, or fixing several other long-standing
> issues with GCC we spend a lot of time refactoring things to be C++.
> But that was kind of part of the decision (though I remember that we
> mainly wanted to convert containters and isolated stuff, not gimple
> or trees (I bet that'll be next)).
That's a reasonable bet given what's already been said on this list WRT 
gimple.


>
> Of course I don't see contributors of "changes that improve gcc for its users"
> now wasting their time with converting code to C++.  That conversion
> may slow down those people, but only so much.  It'll get more interesting
> with branch maintainance ...
True.  But that's probabl more of an artifact of the engineers involved. 
  David (who's by far the most gung-ho on the C++ front) is fairly new 
to GCC and isn't really in a position right now to drive much user 
visible stuff.  So he's doing what he can right now.

jeff