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

[Trevor Saunders <tsaunders at mozilla dot com>]

On Wed, Nov 06, 2013 at 01:38:23PM -0700, Jeff Law wrote:
> 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.

So, thinking about this more the is_a / as_a is more or less just a
translation of the "union casting" we're already doing, which means
while we may not be getting everything we would like we're atleast
getting as good or better than what we have modulo stylistic tastes.

> 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.

I think that's a reasonable thing to do fwiw.

Trev

> 
> 
> jeff