Callback's flaws

Question

From: http://doc.qt.nokia.com/4.7/signalsandslots.html

Callbacks have two fundamental flaws: Firstly, they are not type-safe. We can never be certain

Answer 1

Well, say Qt wants you to give him a callback that takes a pointer to a QString as its argument: your C++ typedef for the call back will look like:

typedef int (*callback_function)( QString *string);

Now, when this callback is called, you can never be sure that the argument passed is really a QString: in C++, this statement is valid and will very likely crash your callback:

int MyCallback( QString *string )
{
   if(string)
       printf("QString value: %s\n", string->toAscii());
}

/* in another function */
char *badQstring = "Booohhh";
MyCallback( (QString *)badQstring ); // crash, badQstring is not a QString!

Since C++ allows casting, you can never be sure of what type is actually passed to your callback. But, well, this statement is valid to whatever function, even if not a callback.

Answer 2

It's a pointer to a function, and some compilers don't check that in run time there won't be a case where that pointer leads to a function with different parameters than expected.

Answer 3

Please look at sqlite3_exec() as a good example. It's void* parameter is a pointer to a "context object" that is passed into the callback function when the latter is called. It's totally up to the user to be sure that this void* points to a type he expects.

For example, you need some complex class as a "context object". You pass an address of an object of that class into sqlite3_exec() and it's implicitly converted into void*, then when your callback is called you have to cast it back from void* and noone catches you if you cast it to the wrong type.