On Wed, Nov 6, 2013 at 12:42 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Wed, Nov 06, 2013 at 12:31:00PM +0100, Richard Biener wrote: >> > 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. > > But that really affects --enable-checking=yes builds (and only cases where > things aren't inlined). If the price for that is uglier and less readable > code, then the price is just too high. > >> > 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 ... > > If the changes are done at least with some for users useful goal (like > perhaps making gcc usable as a library for JITting etc.), then I can see > the benefit, but as_s<> uglification doesn't seem to be beneficial to > users at all, and IMNSHO much better would be to instead > spend time on what is beneficial to users (restrict, vectorizer > cost model, vectorizer improvements, better diagnostics (say range > locations), ...).
Well, what else, besides as_a<> or keeping the current global accessor functions would you propose? Richard. > Jakub
