QtConcurrent - how do I verify - "all the ducks in the row "? revised
-
OK, I made a typo. Irregardless - I think it is relevant that I said one of the calls works and the other does not . I am getting nowhere in QT forum , and I do not care to discuss it. I have been thru "try this and try that ' with my test code. So - let's cut thru the chase here is my test code snippet
THIS ONE WORKS so the syntax is OK status = hci\_inquiry( dev\_id, len, max\_rsp, NULL, &ii, flags); THIS ONE DOES NOT WORK QFuture future\_hci = QtConcurrent::run( std::bind( hci\_inquiry, dev\_id, len, max\_rsp, NULL, &ii, flags) );
/
What is the difference ? and this is first of series of errors posted
/media/q5/MDI/QT_PROGRAMS/QT/15/5.15.2/gcc_64/include/QtConcurrent/qtconcurrentstoredfunctioncall.h:60: error: no match for call to ‘(std::_Bind) ()’
In file included from ../../../QT/15/5.15.2/gcc_64/include/QtConcurrent/qtconcurrentrun.h:49,
from ../../../QT/15/5.15.2/gcc_64/include/QtConcurrent/QtConcurrent:16,
from /mnt/sde5/QT_PROGRAMS_FULL/MDI_BT/MDI_BT/SUB_FT857/mainwindow_sub_ft857.cpp:15:
../../../QT/15/5.15.2/gcc_64/include/QtConcurrent/qtconcurrentstoredfunctioncall.h: In instantiation of ‘void QtConcurrent::StoredFunctorCall0::runFunctor() [with T = int; FunctionPointer = std::_Bind]’:
../../../QT/15/5.15.2/gcc_64/include/QtConcurrent/qtconcurrentstoredfunctioncall.h:60:10: required from here
../../../QT/15/5.15.2/gcc_64/include/QtConcurrent/qtconcurrentstoredfunctioncall.h:60:57: error: no match for call to ‘(std::_Bind) ()’
60 | void runFunctor() override { this->result = function(); }
| ~~~~~~~~^~Looking at the documentation at Concurrent Run | Qt Concurrent 5.15.8[^], it suggests you should be able to write:
QFuture future_hci = QtConcurrent::run(
hci_inquiry,
dev_id,
len,
max_rsp,
NULL,
&ii,
flags);But as k5054 already said, this is the C/C++ forum. For Qt issues you need to find a specialist forum. My feeling would be to write a small test program using the Qt run function with different parameters to check that it does work for the different situations. Once you overcome that issue then you should be able to focus more on the HCI stuff.
-
Looking at the documentation at Concurrent Run | Qt Concurrent 5.15.8[^], it suggests you should be able to write:
QFuture future_hci = QtConcurrent::run(
hci_inquiry,
dev_id,
len,
max_rsp,
NULL,
&ii,
flags);But as k5054 already said, this is the C/C++ forum. For Qt issues you need to find a specialist forum. My feeling would be to write a small test program using the Qt run function with different parameters to check that it does work for the different situations. Once you overcome that issue then you should be able to focus more on the HCI stuff.
-
No, I cannot "just write ..." QTconcurent will not accept more than 5 parameters, hence std:bind is used to bypass that. I believe I need somebody who can interpret the errors.../.
Member 14968771 wrote:
QTconcurent will not accept more than 5 parameters,
What's your source for this statement. The docs [Concurrent Run | Qt Concurrent 5.15.8](https://doc.qt.io/qt-5/qtconcurrentrun.html) do not mention any limit. Assuming that its a C++ template using a parameter pack, the only limit I would expect would be your pthread stack size, which defaults to 8M, so for all intents an purposes not an issue. One thing I would note is that hci_inquiry returns an int so I think the template parameter to QFuture should probablby be:
QFuture future = QTconcurrent::run( ... )
Keep Calm and Carry On
-
No, I cannot "just write ..." QTconcurent will not accept more than 5 parameters, hence std:bind is used to bypass that. I believe I need somebody who can interpret the errors.../.
Member 14968771 wrote:
QTconcurent will not accept more than 5 parameters
Reminds me of when I worked for a company about to publish a completely rewritten FORTRAN compiler: The release was pushed by one (significant) customer who had run into the old compiler's limit on 99 (ninety-nine) parameters to one function. The new compiler would allow 128 parameters, but it could easily be extended to 256 in future compiler versions. I sort of accept that when going above a certain limit (isn't it 4 for the ARM ABI?), there is an increased cost. Five is probably acceptable. The day it grows beyond 99, I think you are on the wrong track :-)
-
Member 14968771 wrote:
QTconcurent will not accept more than 5 parameters,
What's your source for this statement. The docs [Concurrent Run | Qt Concurrent 5.15.8](https://doc.qt.io/qt-5/qtconcurrentrun.html) do not mention any limit. Assuming that its a C++ template using a parameter pack, the only limit I would expect would be your pthread stack size, which defaults to 8M, so for all intents an purposes not an issue. One thing I would note is that hci_inquiry returns an int so I think the template parameter to QFuture should probablby be:
QFuture future = QTconcurrent::run( ... )
Keep Calm and Carry On
I got this second hand and did not bother to verify the parameters # limit. I am busy rebuilding my text code and will be able to try the function without std::bind. Well - until I can get pass the errors I really do not care if the return values is wrong. That puts me back to the original post - how do I know which is causing the error - wrong parameters , wrong # of parameters , incorrect return ... all of these are C++_ issues , very little to do with QT. ( ...but for some who cannot read it looks as QT problem...) Cheers
-
I got this second hand and did not bother to verify the parameters # limit. I am busy rebuilding my text code and will be able to try the function without std::bind. Well - until I can get pass the errors I really do not care if the return values is wrong. That puts me back to the original post - how do I know which is causing the error - wrong parameters , wrong # of parameters , incorrect return ... all of these are C++_ issues , very little to do with QT. ( ...but for some who cannot read it looks as QT problem...) Cheers
Here us my latest test code it does prove that Qt Concurrent takes max of five "arguments" and lets leave it be... Secondly I found the "ducks" error. And not sure how to react to it. QT passes "arguments" to the run function , then QT expect / does this ( as a example ) int integer = 5; if the argument is of "TYPE" integer. ( I have not tried to assign any arbitrary symbol ) then QT expect the symbol "integer" to passed as (??) to the "run" function... ..and it it fails , it identifies the failure source as "TYPE" not as parameter or argument - just "TYPE"... Maybe that is normal , but what a pain to debug.
extern int bFunction( int arg1, int arg2, int arg3, int arg4, int arg5, int arg6, int arg7, int arg8 ); int integer = 5; QFuture future = QtConcurrent::run( std::bind( bFunction, integer, integer, integer, integer, integer, integer, integer, integer ) );
-
No, I cannot "just write ..." QTconcurent will not accept more than 5 parameters, hence std:bind is used to bypass that. I believe I need somebody who can interpret the errors.../.
-
I got this second hand and did not bother to verify the parameters # limit. I am busy rebuilding my text code and will be able to try the function without std::bind. Well - until I can get pass the errors I really do not care if the return values is wrong. That puts me back to the original post - how do I know which is causing the error - wrong parameters , wrong # of parameters , incorrect return ... all of these are C++_ issues , very little to do with QT. ( ...but for some who cannot read it looks as QT problem...) Cheers
-
Member 14968771 wrote:
QTconcurent will not accept more than 5 parameters
Reminds me of when I worked for a company about to publish a completely rewritten FORTRAN compiler: The release was pushed by one (significant) customer who had run into the old compiler's limit on 99 (ninety-nine) parameters to one function. The new compiler would allow 128 parameters, but it could easily be extended to 256 in future compiler versions. I sort of accept that when going above a certain limit (isn't it 4 for the ARM ABI?), there is an increased cost. Five is probably acceptable. The day it grows beyond 99, I think you are on the wrong track :-)
-
Here us my latest test code it does prove that Qt Concurrent takes max of five "arguments" and lets leave it be... Secondly I found the "ducks" error. And not sure how to react to it. QT passes "arguments" to the run function , then QT expect / does this ( as a example ) int integer = 5; if the argument is of "TYPE" integer. ( I have not tried to assign any arbitrary symbol ) then QT expect the symbol "integer" to passed as (??) to the "run" function... ..and it it fails , it identifies the failure source as "TYPE" not as parameter or argument - just "TYPE"... Maybe that is normal , but what a pain to debug.
extern int bFunction( int arg1, int arg2, int arg3, int arg4, int arg5, int arg6, int arg7, int arg8 ); int integer = 5; QFuture future = QtConcurrent::run( std::bind( bFunction, integer, integer, integer, integer, integer, integer, integer, integer ) );
Did some testing of my own over the weekend and I can confirm that
QtConcurrent::run()
does not like more than 5 parameters. Maybe the thing to do is to look intostd::async, std::future
as it does not seem to be limited and provides the same functionality. There's a couple of videos on them here: [C++ Weekly - Ep 9 std::future Quick-Start - YouTube](https://www.youtube.com/watch?v=iCL6GYoi1RU&list=PLs3KjaCtOwSZ2tbuV1hx8Xz-rFZTan2J1&index=9) and here: [C++ Weekly - Ep 11 std::future Part 2 - YouTube](https://www.youtube.com/watch?v=ZgN1-i095QY&list=PLs3KjaCtOwSZ2tbuV1hx8Xz-rFZTan2J1&index=11). Unless there's something inQtConcurrent
that ties in better with your QT project,std::async
andstd::future
may server you better. As a point of interest, why QT? If you're on Ubuntu, and not using Kubuntu, I would have thought that maybe GTK+ would provide a more consistent look-&-feel. There are C++ bindings available (gtkmm), so if you're on a QT/C++ learning curve it would be about the same for you. There's no integrated IDE with gtk, but there's plenty of IDE's out there that will play nicely. Or you could go "hardcore" and learn how to write Makefiles!Keep Calm and Carry On
-
Did some testing of my own over the weekend and I can confirm that
QtConcurrent::run()
does not like more than 5 parameters. Maybe the thing to do is to look intostd::async, std::future
as it does not seem to be limited and provides the same functionality. There's a couple of videos on them here: [C++ Weekly - Ep 9 std::future Quick-Start - YouTube](https://www.youtube.com/watch?v=iCL6GYoi1RU&list=PLs3KjaCtOwSZ2tbuV1hx8Xz-rFZTan2J1&index=9) and here: [C++ Weekly - Ep 11 std::future Part 2 - YouTube](https://www.youtube.com/watch?v=ZgN1-i095QY&list=PLs3KjaCtOwSZ2tbuV1hx8Xz-rFZTan2J1&index=11). Unless there's something inQtConcurrent
that ties in better with your QT project,std::async
andstd::future
may server you better. As a point of interest, why QT? If you're on Ubuntu, and not using Kubuntu, I would have thought that maybe GTK+ would provide a more consistent look-&-feel. There are C++ bindings available (gtkmm), so if you're on a QT/C++ learning curve it would be about the same for you. There's no integrated IDE with gtk, but there's plenty of IDE's out there that will play nicely. Or you could go "hardcore" and learn how to write Makefiles!Keep Calm and Carry On
I appreciate confirmation of the parameters # limit . I do not see why QT limitation of one process would be a reason to switch OS, especially when using std::bind "fixes " this limitation. I have SUCCESSFULLY codded and run several test function using QTConcurrent, and I am basically back where I started. I could use some more assistance with this. The attached code is direct from QT documentation. What I do not understand is the necessity of highlighted code. What is the purpose and is there a doc I could RTFM to get some understanding why this code is necessary. If I pass the aFunctionWithArguments function arguments at face value I then get the "type" error ( as posted previously ) Is this something "just QT " or is that "normal" C++ and if so what is the correct terminology of doing this ? I just call it "SYMBOLS". My real code gets complicated because I am a passing more the 5 "arguments" and two of them are pointer and double pointer. I can run my test function passing struct and have no need for these "SYMBOLS". I am NOT asking to write my code, I am asking for explanation why QT is using these "conversions / symbols "
extern void aFunctionWithArguments(int arg1, double arg2, const QString &string);
int integer = ...;
double floatingPoint = ...;
QString string = ...;QFuture future = QtConcurrent::run(aFunctionWithArguments, integer, floatingPoint, string);
-
I merely said, "the documentation suggests ...". I do not have Qt on my system so I am not able to test it.
As a debugging note if just the number of parameters passed, irregardless if the are "plain arguments" or these funky symbols do not match - the error is "run" " cannot find the function " . The "TYPE" error is definitely my wrong way of "symbolizing" the pointers. Unfortunately the error does not clearly identify which "symbol" is not correct. I'll try to find a real hci function which does not use pointers to verify this assumption.
-
As a debugging note if just the number of parameters passed, irregardless if the are "plain arguments" or these funky symbols do not match - the error is "run" " cannot find the function " . The "TYPE" error is definitely my wrong way of "symbolizing" the pointers. Unfortunately the error does not clearly identify which "symbol" is not correct. I'll try to find a real hci function which does not use pointers to verify this assumption.
Here is "semifinal " version of WORKING code
//int status = hci\_inquiry(adapter\_id, inquiry\_length, //max\_devices, NULL, &inq\_inf,flags ); int status = 10; qDebug() << "Status " << QString::number(status); time->start(); status = hci\_inquiry( dev\_id, len, max\_rsp, NULL, &ii, flags); time->start(); // run QtConcurent QFuture future = QtConcurrent::run( std::bind( hci\_inquiry, dev\_id, len, max\_rsp, lap, //NULL, &ii, flags) ); //TOK future.waitForFinished(); // test only need QTFutureWatcher qDebug() <<"hci\_inquiry elapsed time " <elapsed()); qDebug() <<"hci\_inquiry result " <
I STILL do not understand why "plain function : usage " works with "lap" as NULL and QtConcurent usage DOES NOT. As I said before - I am not so sure I have only one version of hci_inquiry....
The be truthful - I need to get back to source code and try to build my own description for the hci_inquiry code.
It has been educational so far....
PS by semifinal - I need to "move" the QT version to its own object / library.
-
Here is "semifinal " version of WORKING code
//int status = hci\_inquiry(adapter\_id, inquiry\_length, //max\_devices, NULL, &inq\_inf,flags ); int status = 10; qDebug() << "Status " << QString::number(status); time->start(); status = hci\_inquiry( dev\_id, len, max\_rsp, NULL, &ii, flags); time->start(); // run QtConcurent QFuture future = QtConcurrent::run( std::bind( hci\_inquiry, dev\_id, len, max\_rsp, lap, //NULL, &ii, flags) ); //TOK future.waitForFinished(); // test only need QTFutureWatcher qDebug() <<"hci\_inquiry elapsed time " <elapsed()); qDebug() <<"hci\_inquiry result " <
I STILL do not understand why "plain function : usage " works with "lap" as NULL and QtConcurent usage DOES NOT. As I said before - I am not so sure I have only one version of hci_inquiry....
The be truthful - I need to get back to source code and try to build my own description for the hci_inquiry code.
It has been educational so far....
PS by semifinal - I need to "move" the QT version to its own object / library.
Try using
nullptr
instead of NULL. NULL is defined as a macro, often the equivalent of#define NULL ((void *)0)
. That was fine for C, but C++ has stricter rules about converting to/from NULL pointers, so you should use nullptr, particularly when you want to pass a null pointer to a function.Keep Calm and Carry On