Hi,
I am working my way into Allegro (thanks to all the kind people here;D) and trying to understand OO, what I want to do is create my own timer-object, so I can easely manage allegro-timers.

Here is my code:

Timer.h:

Timer.cpp:

But when I try to compile this one, I get the following error:
timer.cpp:14: error: argument of type ‘void (Timer::)()’ does not match ‘void (*)()’

Which is understandable, but I dont know how to solve this one:-/.

You must make Timer::increaseValue static.

But when I set it up like this:

static void Timer::increaseValue()
{
  itsValue++;
}
END_OF_FUNCTION(increaseValue);

It says:
timer.h:13: error: invalid use of member ‘Timer::itsValue’ in static member function

Because static methods must use static properties only.

You should study Object Oriented Programming before to apply it, shouldn't you?

Of course. You can only access static members from a static function.

I think you're right

goes to read the rest of the book, instead of only the basics

But, with install_param_int_ex, you can pass a void* parameter to that static function. If that void* parameter is a Timer*, you can do this:

static void Timer::increaseValue(void* parm) {
    Timer* t = (Timer*) parm;
    t->itsValue++;
}

You shouldn't use C-style casting in C++...

//Timer* t = (Timer*) parm;
Timer* t = static_cast<Timer*>(parm);

But otherwise CGamesPlay is right. Making a static method which takes a pointer to an object of the class is the usual approach for such problems (providing function callbacks for C-APIs in C++).

Thats fugly. I prefer (Timer*) style cast.

And they are the same damn thing.

No. The C-style cast can have the effect of reinterpret_cast. static_cast ensures that the cast is possible, check is being performed at compile time.

Hey Miran did it before you. Copy from his masking lib.;D

And both reinterpret_cast and static_cast will work. who'd a thunk it.

Stroustrup himself said the real reason for all those casts was to make casting an ugly operation that is hard to type. Stroustrup's ideal is a program with no casts.

I disagree with him, I integrate casts into my everyday life. Therefore i chose to ignore that part of his C++ standard.

First and foremost, it doesn't in this case, without a doubt. Now, can you point out a case where it does?

static void Timer::increaseValue(void* parm) {
    Timer* t = (Timer*) parm;
    t->itsValue++;
}

void evilFunction( )
{
  NotTimer nt;
  Timer::increaseValue((void*)&nt);
}

Tadaa! Runtime error.

using void in a C++ program is retarded (in most cases) to begin with, just don't.

So, it's bad because the user can craft a method to break it? Then reinterpret_cast<> is bad because the user can skip checking for a NULL (sorry, I mean 0) return, to cause a run-time error.

Why would you ever ever pass the pointer to some random object to a function? No. you just dont.

You read the function's documentation and you figure out what the function needs. If you're not gonna do that you shouldn't be programming. At least not within 100 miles of me.

[edit]
If you're in the habit of passing pointers to random things to functions, then you're pretty evil. I wont put my coding standards around something in case i have to work with an evil coder.

[edit]
On second though, you're post doesn't quite make sense to me. Heres a modified version that works just as well.

static void Timer::increaseValue(void* parm) {
    Timer* t = reinterpret_cast(Timer*) parm; // static_cast will not compile here
    t->itsValue++;
}

void evilFunction( )
{
  NotTimer nt;
  Timer::increaseValue((void*)&nt);
}

[edit]
Made my post less harsh sounding.

Just because it's possible to do bad things in a language, that doesn't mean you should. Most of that sort of constructs in C or C++ have their reason to exist, but shouldn't be used in general, except there's a very good reason to do so. And mostly, there are several ways to accomplish whatever is desired, so it's the programmer's task to choose the better ways whenever possible...

After reading a few chapters of my book I think I have achieved what I wanted to do.

Anyway, I just wanted to show you how I have done it:

Aww. Of course my "problem demonstration" code doesn't make much sense. I was just trying to point out that static_cast is NOT the same as normal C-style casting, which is the same as reinterpret_cast which is not as safe as static_cast, which in turn is not the same as normal C-style casting ... (endless loop)

Anyway,
I suppose when you mess (or have to mess) with void pointers, it doesn't make much difference anymore, as static_cast only has advantages over reinterpret_cast when dealing with class hierarchies.

This also means that my first post in this thread didn't make much sense either.. sorry!

I is always good to see different vieuws on a problem:D

I whole-heartedly disagree . While it can be good to get some incentives, in some places there just is no room for discussion, especially when working in a team. This of course requires all team members to be able to cut down their ego, or the whole thing collapses. Which is inevitable in either case, with a team of dogmatic members you are screwed anyway. What was my point? Oh yeah:

Fixed.

Oh, and also, it is almost never good to derail a discussion and be nit-picky. Alas, my apologies for doing so.

Yeah. I experienced this several times. Either the whole thing collapses or one person takes over and does everything alone.