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

[Richard Biener <richard dot guenther at gmail dot com>]

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".

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
>
>