On 04/22/2014 02:56 PM, Richard Sandiford 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.

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.



Can we also consider making dyn_cast handle NULL at the same time? the C++ dynamic_cast<> does, and I ended up supporting it in my branch as well.


so dyn_cast would be more like:

inline T
dyn_cast (U *p)
{
  if (p && is_a <T> (p))
    return is_a_helper <T>::cast (p);
  else
    return static_cast <T > (0);
}


both is_a<> and as_a<> would still require a valid pointer or you get a NULL dereference...


I've found it very pragmatic...

Andrew

Reply via email to