This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]