This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 00/89] Compile-time gimple-checking
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: David Malcolm <dmalcolm at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 22 Apr 2014 19:56:56 +0100
- Subject: Re: [PATCH 00/89] Compile-time gimple-checking
- Authentication-results: sourceware.org; auth=none
- References: <1398099480-49147-1-git-send-email-dmalcolm at redhat dot com> <877g6hhjti dot fsf at talisman dot default> <1398186366 dot 26834 dot 95 dot camel at surprise>
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.
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