ITimer and abstract classes for the beginner

[wizard4]

First, since ITimer is an Interface (hence the 'I'), you must publicly inherit from it for the class 'MyTimer'. Now proceed to write the entire class functionality, including all virtual = 0 methods.

From a beginner's viewpoint, why doesn't Timer know how to get the time, since all the methods are there already?

My only conclusion is it allows you to write your output code in a format you like, but how I'd even begin to program start() is way above my head.

For the novice, try device->sleep. Like I did.

[CuteAlien]

You don't have to inherit to use it. Or write the class. As user you just use the timer and don't have to care about the implementation.

If it makes sense to work with an virtual interface in this specific case is a bit harder to tell. It's more like - Irrlicht uses this object oriented style which was very fashionable for a while (around the time Java was new) nearly throughout it's code. For a timer - it's really just same code implemented on different platforms, there's likely zero chance anyone ever codes 2 different timers on the same platform. So one could say the abstract interface here isn't exactly necessary. Then again it doesn't hurt too much usually (tiny cost due to virtual function call overhead).

So basically - it's just a style of coding. One could code the same in other styles.

If you try to do things like change the output, don't derive your own class. Just access this class _in_ your class (or don't use it at all).

[wizard4]

Noiecity did rescue me a bit.
and
viewtopic.php?t=723

Code: Select all

ILogger* logger = device->getLogger();

Is it as simple as creating a pointer?

Code: Select all

ITimer* timer = device->getTimer();

I can see pointers are very handy to pass around.

[CuteAlien]

As long as you make sure the pointer is pointing to an actual object in memory they are very nice to use.

With Irrlicht that mostly means being careful with reference counting: https://irrlicht.sourceforge.io/docu/cl ... unted.html
Irrlicht has caches for the most common stuff (so objects stay in memory), so usually with Irrlicht you are fine.

In your own classes you have to find your own ways to make certain pointers are always valid.
Every time you use a pointer think a bit about: Is that object already created and is it still in memory right now.
As long as don't mess that up they are nice. If you mess that up pointers can get very ugly and the compiler can't help you with this one.

If you use modern c++ and work with smart pointers (https://en.cppreference.com/book/intro/smart_pointers) then the compiler can help you a bit. But those don't mix too well with Irrlicht reference counting (or many other libraries really), so it will always be something you have to be careful with.
And I think it helps a bit to understand raw pointers first as it makes it easier to get when and why smart pointers help.

One thing that helps a lot and you should make a habbit is: Always ensure every pointer is initialized to a value. So if you have a pointer variable which is not yet set to an object, then initialized it with 0 (or with 'nullptr' if you work with a modern c++ compiler). With modern compiler you can do that always directly in the header. If you support older compilers like Irrlicht then it's done in the constructor (don't do that, just use a modern compiler). And also other way round - once you release an object, set the pointer to 0 afterwards. That will help you a lot because now you can always check if a pointer is already initalized to something by checking if it's not 0. And also functions which return pointers generally return 0 if they have errors. For example if a mesh doesn't load in Irrlicht it will return a 0 pointer.