On Wed, Nov 6, 2013 at 12:02 PM, Bernd Schmidt <ber...@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. > I still think all this effort is misdirected and distracts us from > making changes that improve gcc for its users. 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)). 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 ... Richard. > > Bernd >
