Printable View
Hi all,
Can any one please help me in understanding( may be with an example) that how callbacks are not type safe and how Qt's signal/slot overcome this or can say that how Qt's signal/slot is typesafe?
i may be wrong. so plz correct me if i m badly gng out of track. C callbacks are not typesafe but c++ callbacks are type safe, so as Qt is a C++ GUI toolkit, it is typesafe?
When you register a callback in C, it is usually by passing a void * pointer (or a function pointer) to a register function. The problem is that you can pass a pointer to any function, even one that has completely different arguments than the callback mechanism expects. When such a method is then called, it can assume a completely different stack frame and either corrupt the frame or rely on a bogus return address (or both). In all cases it'll at least cause the application to crash.Quote:
Originally Posted by Shuchi Agrawal
Qt does a signature check upon making the connections (that's essentially what moc is for) and does that without relying on types of pointers or anything like that but on the textual code generated by moc (open some moc_*.cpp file in your text editor and see what's inside).Quote:
and how Qt's sagnal/slot overcome this or can say that how Qt's signal/slot is typesafe?
C++ "callbacks" are most often realised by reimplementing some virtual method (like with all event handlers in Qt), therefore it's type safe, as you can't modify the argument list of such a method (if you do, you'll create a different method instead of overriding the base class implementation).Quote:
C callbacks are not typesafe but c++ callbacks are type safe, so as Qt is a C++ GUI toolkit, it is typesafe?
Thanks a lot.
But i still have some doubts.
Following is some code for a callback approach :
/* LIBRARY CODE */
int traverseWith(int array[], size_t length,
int (*callback)(int index, int item, void *param),
void *param)
{
int exitCode = 0;
for(int i = 0; i < length; i++)
{
exitCode = callback(i, array[i], param);
if(exitCode)
{ break; }
}
return exitCode;
}
/* APPLICATION CODE */
int search(int index, int item, void *param)
{
if(item > 5)
{
*(int *)param = index;
return 1;
}
else
{ return 0; }
}
/* (in another function) */
int index;
int found;
found = traverseWith(array, length, search, &index);
if(found)
{
printf("Item %d\n", index);
}
else
{
printf("Not found\n");
}
Can u please read the code and explain that how this code can be type-unsafe in c or C++
and how it can b type-safe in Qt.
This is a signature of a callback function pointer returning an int and taking two ints and a void*.Code:
If I'm correct you could do the following:
I cast the functor to a type the "traverseWith" function expects so the compiler shouldn't interfere. And when you call the above line, the compiler will create a frame stack for a method that expects a return value and has three arguments. But the function which actually is called expects a completely different frame stack, which will lead to stack corruption and a crash.Code:
In C++ you'd use function objects based on templates, which do type checking, etc. making it a bit safer (you pass around objects and not pointers). Qt uses a simmilar approach (for example when sorting).
ok. thats fine. so am i right if i say that signal/slot is type safe because of C++ type safe ability?
fm the above explanation, can i say that it depends on the use that how one code. we can make all type safe if we code properly?
No. Signals and slots use a completely different mechanism. They are type safe because each signal and slot has a textual signature which is checked and compared to the other signature during connection, so it is Qt that assures that appropriate methods get connected. C++ has nothing to do with that.Quote:
Originally Posted by Shuchi Agrawal
In the simplest cases, yes.Quote:
fm the above explanation, can i say that it depends on the use that how one code. we can make all type safe if we code properly?
But the example you provided is not exactly what I'd call a callback. If you use C++, you should avoid such constructions in favour of using classes.
Yes, Qt's signals are typesafe. When the connect() call is made, to connect a signal to a slot, the parameters are strictly checked. This is done at runtime, not compile time, so you get the advantage of type safety with runtime objects, which are great for components and plugins.Quote:
Originally Posted by Shuchi Agrawal
But there's more than just type safety. When you get to OO and C++, you encounter a new problem which I call the "dangling callback" problem. Unfortunately, this is all too common in GUI toolkits. You invokde a callback method, but the object has been destroyed, and so you get a memory fault.
But Qt's signal/slots are safe here as well. You cannot get a dangling callback, because Qt does not use callbacks internally. You can safe emit a signal even if all the objects with connected slots have been destroyed. There is no problem.
In reality, you pass QVariant or some sort and deserialise to some object by manual type checking, so you might as well call it type unsafe. Other languages with real type safety wouldn't even allows you to compile it.Quote:
Originally Posted by Brandybuck
Casting from void pointer would be comparable and actually better performance-wise if it was supported.
This thread is 18 years old, started in 2007 back in Qt3 / Qt4 days. Things have changed.
No, in reality you can pass whatever you want in a signal / slot connection, anything from a fundamental type to an entire class, by value, reference, or pointer. If you want to abuse signals and slots, you use QVariant. A signal or slot is no different than a normal class method.Quote:
In reality, you pass QVariant or some sort
And modern Qt (Qt5 and Qt6) syntax for connect() uses references to functions which are evaluated at compile time for type checking. It is completely type safe unless you abuse it with void pointers or QVariant.