Should I use busy waiting in QThread
-
I have a QByteArray and want to fire a signal once the array changes.
Since QByteArray doesn't have signals, I thought of creating a QThread which constantly checks (infinite while loop) if the array has changed and emits the signal if so.My question: is it a good idea to use busy waiting, will this not heavily effect my processor ("heavily" in terms of a simple function)?
-
I have a QByteArray and an external library writing to the array. I have no control over the library, so I don't know when it will write into the array. Once written, my app should detect the change and process the new data written into the array.
-
It depends on your timing constraints. If you need an immediate notification busy waiting might be the way to go. In all other cases I would prefer a timer, which checks the byte array in regular intervals, for example 10 ms or 100 ms. This way you waste much less processing power.
-
I don't know if this will work or if it is worth the effort. You could write your own implementation of QByteArray and reimplement the function which is used by the external library to write to the QByteArray. Your implementation of the QByteArray is essentailly the same except that you will emit a signal when the function is called.
For example:
@
void MyByteArray::push_back ( const char * str )
{
QByteArray::push_back(str);
emit byteArrayChanged();
}
@Your custom bytearray is stored as a pointer to a QByteArray:
@
QByteArray* myByteArray = new MyByteArray();
@ -
Ahh, why didn't I see that. But I'm not totally sure if the library is using the push_back function. But a little bit of testing will give me a result.
Thanks KA510 -
Subclassing QByteArray to add the functionality will not work! [[Doc:QByteArray]] does not use virtual methods, and thus calling push_back on the myByteArray pointer will not call your (=MyByteArray's) implementation, but that of QByteArray.
Also, for signals to work, your class has to inherit from [[Doc:QObject]], which in turn disables the copy constructors and assignment operators which are assumed to work with QByteArray.
-
Volker:
I've subclassed QByteArray and made it also inherit from QObject (for the signals) and it works perfectly. So MyByteArray's push_back DID GET CALLED.
-
bq. From "C++ FAQ 20.3":http://www.parashift.com/c++-faq-lite/virtual-functions.html:
Non-virtual member functions are resolved statically. That is, the member function is selected statically (at compile-time) based on the type of the pointer (or reference) to the object.So your push_back method is not called if you call it from a QByteArray pointer.
@
MyByteArray *mba = new MyByteArray();
mba->push_back('a'); // calls MyByteArray::push_back()QByteArray *qba = new MyByteArray();
qba->push_back('a'); // calls QByteArray::push_back()
@ -
Yip, first one works. But I'm not using polymorphism anywere, so the second statement doesn't really matter.
-
[quote author="goocreations" date="1326800282"]Volker:
I've subclassed QByteArray and made it also inherit from QObject (for the signals) and it works perfectly. So MyByteArray's push_back DID GET CALLED.[/quote]Well, I guess you are concealing something from us then, because as Volker said, passing a derived class through a base class pointer will make you lose any polymorphism when using non-virtual methods.
Do you mind sharing that piece of code that shows the interaction between the QByteArray subclass and the library?
-
These two statements are contradictory:
[quote author="goocreations" date="1326801856"]Yip, first one works. But I'm not using polymorphism anywere, so the second statement doesn't really matter.[/quote]
[quote author="goocreations" date="1326786985"]I have a QByteArray and an external library writing to the array.[/quote]
If you do not change your external library, then that one is going to use a QByteArray value or reference. And voilà, polymorphism is introduced, the library will call the base class implementation.
-
I see that know, going back to the checking QThread again. Thanks Volker