On Thu, Apr 24, 2014 at 4:49 PM, Michael Matz <[email protected]> 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.
