This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Wed, 6 Nov 2013, Jakub Jelinek 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 see static type checking as being about preventing certain sorts of bugs 
getting in the compiler at all, rather than about saving time on runtime 
checks for --enable-checking=yes.

I don't have advice on the gimple case.  But certainly trees and RTL could 
both do with more static typing.  There, I'm thinking of different types 
of objects (types, expressions, ...) logically being completely separate 
static types, not inheriting from a common "tree" base class at all.  But 
if inheritance and as_a can be used as intermediate steps to allow an 
incremental transition to completely separate static types, where 
otherwise the whole source tree would need converting at once, that seems 
reasonable to me. (I have no comments about what things should look like 
in cases where completely separate static types don't make sense but there 
is still some sort of inheritance structure.)

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]