[Solved] C++ and abstract classes in irrlicht: Confusion

[whisp]

I have serious problems in understanding the abstract classes used in C++ respectively implemented in Irrlicht.

I understand the usage and usefulness of interfaces, but i am confused about the explanations of abstract classes in miscellaneous C++ tutorials but their to those explanations conflicting usage (or even possibility to use) in Irrlicht, respectively the Irrlicht-Tutorials.

What i learned is, that a class with a virtual member with =0 at the end is an abstract class, and that the function with the =0 can't be defined in that class. In Irrlicht are several such functions which are used in several Irrlicht-Tutorials and they obvisously do something, even though they theoretically aren't defined.

The irr::video::IVideoDriver class e.g. has a method virtual void setMaterial (const SMaterial &material)=0 which is used in the onRender method of ISceneNode.

Why does this method something, even though it is not defined? What did i not understand?

Thanks for any answers!

[bitplane]

The interfaces define how you communicate with the underlying implementations, it's like an object-oriented protocol.

Here's a snippet from a tutorial I never finished writing:

An API, or Application Programming Interface, can be seen as a collection of rules for using a service. An example of an interface in the real world would be the technical specifications for a phone socket, this set of rules lets manufacturers know what the plug looks like and which signals need to be sent along each pin. Manufacturers are free to create a telephone, answering machine or a modem without worrying about the telephone exchange it will be connected to, and the exchange can connect calls for any device that has the right cable and speaks the right language.

A C++ API obviously isn't a collection of documents that describe physical sockets, it's a collection of C++ header files that describe how you use the service. Irrlicht is a graphics library, so it provides a rich set of interfaces that allow you, the application programmer to load, draw, organise and manipulate 2D and 3D graphics.

How does it work?

The Irrlicht Engine's interfaces are classes that begin with the letter I, there are lots of them but the most important ones are the IrrlichtDevice, IVideoDriver and ISceneManager.

<<picture of an artists easel, paint brush, brain>>

In this example the IrrlichtDevice is the easel, it holds the thing you want to draw on (the canvas). You just ask Irrlicht to create an IrrlichtDevice and depending on your operating system you'll get somewhere to draw things without needing to know exactly what type of device it really is, they all work the same. Creating an IrrlichtDevice usually means a window will be created, in Microsoft Windows you'll get a Win32 Window, in Linux an X11 window and in Mac OSX a Cocoa window without needing to know the Win32 API, X11 API or Cocoa API, and of course the same applies to Windows Mobile, iPhone, Symbian, SDL and console devices.

IVideoDriver is the brushes and palette that you use to draw stuff onto the device, this is usually done by telling your graphics card to draw some triangles using a certain material. Again IVideoDriver abstracts the different types of rendering APIs, in Windows you might want to use a DirectX driver, in Linux and Mac OSX you'd use OpenGL, on the iPhone you'd use OpenGL ES, and on a system with no graphics hardware you'd use a software driver.

[whisp]

Thanks for your answer. I do however still not understand why a method that could not be defined, due to the virtual ... =0, still does something. How i understood it is, that a method like this is just declared to ensure, that it will be implemented in a inherited class. But i see driver->setMaterial often be successfully used directly from the baseclass itself.

[Mel]

It does something because although the IVideoDriver class has most of its members defined as abstract, there are another classes: CD3D9VideoDriver, COpenGLDriver, CNullDriver... which inherits from that IVideoDriver class and implement the abstracted methods.

The abstract methods are virtual, which means that the corresponding functionality they will show won't be known until the program is run, and the exact functions are then linked properly.

Say you have class A, which has abstract method "doSomething()"

Code: Select all

class A{
public:
virtual void doSomething() = 0;
};

As it is, this class can't do anything on its own because there is no code of its own.

The inheritance rules say that an object of a child class can be treated as an object of the base class. But we can overload the base methods, in this case, the abstract ones.

Code: Select all

class B:public A{
public:
void doSomething();
};

//...implementation of the method doSomething in class B.

void B::doSomething(){a+b;}

The good news is that although the base class is abstract and cannot be instantiantiated, the children classes are instanceable, can be treated as objects of the base class, and when you call the abstract methods of the base class, this will cause the runtime to link and execute actually those of the class B, like this:

Code: Select all

A* myVarA;
B* myVarB;

B = new B;

myVarA = myVarB;

myVarA->doSomething();// This really runs myVarB->doSomething()!!

This is what is called "polimorphism". The point is that knowing only the methods of the base class, Irrlicht can use any method of the children classes. That is why the classes that have a method defined as abstract are also called "interfaces"

In irrlicht many of the elements that compose it are called through interfaces. It simplifies the usage, and yet, allows for an extreme versatility.

[whisp]

Thanks for the detailled info, Mel!

I already knew the second part of your explanation (about the base class insect with a run method that works different for ants and spiders) but i wasn't aware about the CD3D9VideoDriver, COpenGLDriver, CNullDriver child-classes you mentioned. I even checked the inheritance hierarchy in the docs and there was nothing inheritted from IVideoDriver (in the docu), yet this must be, because this childclasses aren't accessible by the Irrlicht-User. I'm pretty new to C++ (and Irrlicht) and there are a lot of unsurenesses, thus i'm pretty easily confused when something looks like i wouldn't have assumed it.

However, your explanation really enlightened me. Thanks!