On Thu, Apr 24, 2014 at 4:49 PM, Michael Matz <m...@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.