Programming - Interfaces

[Nev]

I'm writing my first ever interfaces (in the C#/C++ sense - in C++, completely pure virtual base classes) for my project, and I have to say I'm digging them. Seems that interface-based programming is a bit more work at the start, but it lets me do things I could never do without them. I'd always known polymorphism, and specifically, not having to know an object's final derived type when it's used, just the interfaces it supports, is a very powerful technique, but it's something else entirely to see it in action. I won't go into detail because it would take forever, but I'm able to implement a generic framework for the game that absolutely wouldn't be possible without them.

I'm becoming a pretty big Bjarne Strousoup fan...

[Andrew, Killer Bee]

I'd always known polymorphism, and specifically, not having to know an object's final derived type when it's used, just the interfaces it supports, is a very powerful technique, but it's something else entirely to see it in action.

How does this work in a statically typed language like C++?

I'm a big fan of <a href="http://en.wikipedia.org/wiki/Duck_typing">duck typing</a>. I've found that I very rarely care about an object's type, just what it can do. Python is great for this; Ruby is too, apparently, although I've never written Ruby.

[Nev]

I may be a fan of it as well, though I haven't ever really used Python. My friend, who's quite a good, Stanford-educated programmer, swears by Python, I think largely because of that. Sadly, though, Python interpreters are not presently there for ARM processors (at least as far as I'm aware). My guess is that C++ is still faster and more suitable for gaming anyway, though I've never really looked.

In C++, instances of classes further "up" the inheritance hierarchy (or base classes if you will) are not compatible with their derived classes, but pointers to base classes are. So you might have IBase, and CDerived that inherits from IBase, in which case the following would be legal:

Code: Select all

IBase* basePointer;
CDerived derived;
basePointer = &derived;   //legal

[Ishamael]

I

I'm a big fan of <a href="http://en.wikipedia.org/wiki/Duck_typing">duck typing</a>. I've found that I very rarely care about an object's type, just what it can do. Python is great for this; Ruby is too, apparently, although I've never written Ruby.

This is true in general, hence the explosion of dynamically typed languages of late. Static typing isn't nearly as important or life saving as people used to think.

[Nev]

I've never actually used a modern and dynamically typed language. I ought to do so just to see what it's all about.

Perhaps Python is one to try. I've traditionally been squeamish about interpreted languages because of the speed hit, but I really don't know much about real-world cases relating to Python...

[Ishamael]

I've never actually used a modern and dynamically typed language. I ought to do so just to see what it's all about.

Perhaps Python is one to try. I've traditionally been squeamish about interpreted languages because of the speed hit, but I really don't know much about real-world cases relating to Python...

Hard to say, really. When speed and memory constraints are absolutely tight, then stick to something like C/C++ of course. But you can do a lot of intepreted and/or dynamically typed languages these days and get a significant boost in development time to boot.

[Nev]

I've never actually used a modern and dynamically typed language. I ought to do so just to see what it's all about.

Perhaps Python is one to try. I've traditionally been squeamish about interpreted languages because of the speed hit, but I really don't know much about real-world cases relating to Python...

Hard to say, really. When speed and memory constraints are absolutely tight, then stick to something like C/C++ of course. But you can do a lot of intepreted and/or dynamically typed languages these days and get a significant boost in development time to boot.

Well, in the game industry...I mean, perhaps it's not a complete certainty that speed and memory constraints will be absolutely tight, but I would think it happens more often than not. We certainly are facing them with our project. Lower development time isn't always a boost if your product can't end up competing with others in the market in terms of gameplay and graphics/sound, all of which are heavily speed- and memory- dependent.

J2ME games in the cell phone game industry have a reputation for being often slow and sometimes outright crippled. It may be heavily due to the hardware, but I don't believe the interpreter helps. And the interpreter (the JVM) loading screen is annoying and takes forever compared to BREW.

My guess is my skillset is going to heavily depend on C++ for awhile still.