On Wed, 2014-04-23 at 16:19 +0200, Richard Biener wrote: > On Tue, Apr 22, 2014 at 9:42 PM, Richard Biener > <richard.guent...@gmail.com> wrote: > > On April 22, 2014 8:56:56 PM CEST, Richard Sandiford > > <rdsandif...@googlemail.com> wrote: > >>David Malcolm <dmalc...@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.
Done, as: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01439.html I've experimentally ported patch 2 of the series (gimple_switch) to this approach, dropping the unloved casting methods in favor of as_a and dyn_cast, and it works. > 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". > > Thanks, > Richard. > > > Richard. > > > >>If we ever decide to get rid of the typedefs (maybe at the same time as > >>using "auto") then the choice might be different, but that would be a > >>much > >>more systematic and easily-automated change than this one. > >> > >>Thanks, > >>Richard > > > >