Re: [PATCH 00/89] Compile-time gimple-checking

[Andrew MacLeod <amacleod at redhat dot com>]

On 04/23/2014 10:19 AM, Richard Biener wrote:
> On Tue, Apr 22, 2014 at 9:42 PM, Richard Biener
> <richard.guenther@gmail.com> wrote:
> > On April 22, 2014 8:56:56 PM CEST, Richard Sandiford <rdsandiford@googlemail.com> wrote:
> > > David Malcolm <dmalcolm@redhat.com> writes:
> > > > Alternatively we could change the is-a.h API to eliminate this
> > > > discrepancy, and keep the typedefs; giving something like the
> > > following:
> > > >    static void
> > > >    dump_gimple_switch (pretty_printer *buffer, gimple_switch gs, int
> > > spc,
> > > >                        int flags)
> > > >    [...snip...]
> > > >
> > > >    [...later, within pp_gimple_stmt_1:]
> > > >
> > > >       case GIMPLE_SWITCH:
> > > >         dump_gimple_switch (buffer, as_a <gimple_switch> (gs), spc,
> > > flags);
> > > >         break;
> > > >
> > > > which is concise, readable, and avoid the change in pointerness
> > > compared
> > > > to the "gimple" typedef; the local decls above would look like this:
> > > >    gimple some_stmt;  /* note how this doesn't have a star... */
> > > >    gimple_assign assign_stmt; /* ...and neither do these */
> > > >    gimple_cond assign_stmt;
> > > >    gimple_phi phi;
> > > >
> > > > I think this last proposal is my preferred API, but it requires the
> > > > change to is-a.h
> > > >
> > > > Attached is a proposed change to the is-a.h API that elimintates the
> > > > discrepancy, allowing the use of typedefs with is-a.h (doesn't yet
> > > > compile, but hopefully illustrates the idea).  Note how it changes
> > > the
> > > > API to match C++'s  dynamic_cast<> operator i.e. you do
> > > >
> > > >    Q* q = dyn_cast<Q*> (p);
> > > >
> > > > not:
> > > >
> > > >    Q* q = dyn_cast<Q> (p);
> > > Thanks for being flexible. :-)  I like this version too FWIW, for the
> > > reason you said: it really does look like a proper C++ cast.
> > Indeed. I even wasn't aware it is different Than a c++ cast...
> It would be nice if you can change that with a separate patch posted
> in a separate thread to be more visible.
>
> Also I see you introduce a const_FOO class with every FOO one.
> I wonder whether, now that we have C++, can address const-correctness
> in a less awkward way than with a typedef.  Can you try to go back
> in time and see why we did with that in the first place?  ISTR that
> it was "oh, if we were only using C++ we wouldn't need to jump through
> that hoop".
I was also wondering if we shouldn't be able to get rid of the 'const_' 
versions and just properly use const with the c++ classes.

I think we can...

Andrew