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

[Jeff Law <law at redhat dot com>]

On 11/05/13 16:23, Ian Lance Taylor wrote:
> On Tue, Nov 5, 2013 at 2:12 PM, Jeff Law <law@redhat.com> wrote:
> > I can't speak for Andrew, but my experience with this kind of object type
> > casting in a large C++ project is that it's a red flag for a design problem.
>
> I'm going to chime in to say that I think it's a pretty typical way to
> represent a compiler IR in C++.  There is a base type that a lot of
> code uses, but there is also a real type, and the way to get to that
> real type is to use a cast.  We could do it all with virtual
> functions, but those carry a different cost.  In effect, using virtual
> functions increases the size of the code field from 16 bits to 64
> bits.  It adds up.
>
> Also this seems to be a pretty direct version of the data structures
> we already have.
Certainly and to some degree these casts in one form or another are a 
necessity.  My concern is we use them as a crutch (as I've seen in other 
projects) and we end up not getting the level of compile time static 
type checking that we want.

If the bulk are temporary in nature and we as a project agree to look at 
the refactoring necessary to minimize the is-a/as-a uses to a few low 
level idioms, then I'll hesitatingly go along.  If that's the choice we 
make, then folks should know I'll probably look at each is-a/as-a in 
patches I review and ask for a justification for their use.


jeff