Quote:Original post by Glak
using typeid stuff is pretty much the same as casting, and indicates a problem. You should not need to get derived class information from something assigned to a base pointer. If you want to access Sound or whatever just make it global, either a global variable, global namespace, or global singleton. Some sort of global.

Eh... So you're saying you should use globals instead of casting?

Quote:using typeid stuff is pretty much the same as casting, and indicates a problem.

Note that you don't have to use typeid() in the implementation at all -- I just used it because it's an easy source of strings to use as interface identifiers. You could use names of football teams, or integers, if you want -- as long as you get a unique identifier per interface you may wish to query for.

A second note is that the use I'm making of typeid() is _not_ analogous to dynamic_cast<>, because it is resolved statically at compile time -- it'll work even if you turn off RTTI. Additionally, getInterface() lets you decide what specific classes to let others find pointers to, whereas dynamic_cast<> doesn't let you totally decide -- any public base of a public base will be accessible. Further, dynamic_cast<> doesn't support delegation, whereas getInterface() does. Last, dynamic_cast<> is very, very slow -- the strcmp() implementation of getInterface() I showed is much faster, and a version that uses interned strings or interface registries would be faster still.

A third note is that you CAN make a public accessor for any interface you may wish to get on any interface you may wish to get it from. However, that quickly becomes way too wide, and the getInterface() solution is actually more maintainable and easier to work with. Typical examples come when sorting out entities inside notifications -- i e, entity A collided with entity B, and wants to know whether entity B supports some special kind of resolution. You should NOT make it a rule that every entity needs to support the special resolution rules that entity A wants, nor even an accessor for those rules, or adding/improving your entity behavior system becomes ridiculously unweildy.

In fact, getInterface() allows you to de-couple your logical design from your physical design, which is a major benefit in many game programming situations. I you're going to say it's a bad design tool, then you're going to have to put a LOT more weight behind that statement, with specific examples of what better solution you have to the same problems. ("use a global" isn't, and "make Entity support abstract accessors for anything you might ever want" also isn't)