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

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

On Thu, Apr 24, 2014 at 4:49 PM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Thu, 24 Apr 2014, Andrew MacLeod wrote:
>
>> Well, we ought to settle on one... either use the is_a, as_a, and
>> dyn_cast paradigm as they exist today, or we use the cast_as_method
>> approach everywhere.  I'm not fond of each potential project having a
>> different approach...  I'd like to see a consistent look throughout.
>>
>> I suspect the cast_as_method has compile time advantages, as well as
>> error reporting ones.... (have you seen the kind of message you get when
>> the template instantiation doesn't work right? ick!)  , but it suffers
>> from having to modify the base class whenever a new derived class is
>> added...
>
> Well, when adding new derived classes is such a frequent event that this
> would be of any worry, then we have much more difficult problems.  Adding
> types should be a well thought out and hence rare event.
>
>> (which seems a little "dirty" and could impact possible future
>> enhancements).
>
> Perhaps dirty from some artificial language cleanliness perspective
> (although why would methods be regarded as dirty?).  I call it pragmatic
> and visually undisturbing.

Btw, I agree we should stick to one style throughout the code-base.
The advantage of the cast variant is that it can be made work with
NULL pointers (in the dyn_cast <> case).

Oh, and you could avoid all the base-class changing stuff if you'd
do the method like

class Foo
{
  template <class T> T *as () { return as_a <T> (this); }
}

Best (or worst) of both worlds.

  gimple_cond c = g->as<gimple_cond> ();

;)  (you can even put those methods in a separate feature class you
can simply inherit from)

Richard.

>
> Ciao,
> Michael.