On Wed, Apr 23, 2014 at 4:19 PM, Richard Biener <richard.guent...@gmail.com> 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. > > 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".
To followup myself here, it's because 'tree' is a typedef to a pointer and thus 'const tree' is different from 'const tree_node *'. Not sure why we re-introduced the 'mistake' of making 'tree' a pointer when we introduced 'gimple'. If we were to make 'gimple' the class type itself we can use gimple *, const gimple * and also const gimple & (when a NULL pointer is not expected). Anyway, gazillion new typedefs are ugly :/ (typedefs are ugly) Richard. > 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 >> >>
