Basile Starynkevitch wrote: > Except that perhaps these questions are important for any gengtype > enhancement. In particular, one could consider that marking a GTY-ed > data would be done by a virtual method (generated by gengtype), and then > having every GTY-ed data inheriting from an abstract class providing > this method will make both gengtype & ggc*.c simpler.
There is no pressing need for a gengtype enhancement as far as I can tell. I think the right way to look at this is that we can now use C++ going-forward to implement things, and that is helpful. In some cases, we'll want to convert existing things to C++ because that helps us to do new things. But, we don't need to convert things just because we can. We don't get a prize for having a tidier code base *in and of itself*. I think we should focus on some user-visible deliverable (better optimization, faster compiler, new language feature, plugin API, whatever). If converting something to use C++ helps achieve that goal, great. If it doesn't, then why bother? I'm not saying that we should reject "clean-up" patches that use C++ in some way that makes things notably tidier. I'm just saying that I'm more excited if I see how that patch is going to help us build new functionality. And, I think it's premature to start talking about particular changes to particular parts of the compiler. Step 1 is to agree on the subset of C++ we're willing to use. Step 2 is for someone to propose a C++-using patch that does something useful and get it approved. So far, I've seen a lot of input on Step 1, but nobody that wants to step up and take responsibility for the task. Any takers? -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713