[Solved]Problem using low level I/O
-
wrote on 15 Feb 2015, 14:21 last edited by
Howdy:
I'm porting this app to qt because I want to add a gui. The app does modem i/o and has been well debugged and working smoothly for several years.
It uses "open, close, read, write, and select" to achieve communication with the modem. Everything ported very well with the exception of the close command. It seems that there is a name conflict with some other close statement that the gui stuff uses. Here's the results of my attempted build:
@
09:06:28: Running steps for project CallMonitoring...
09:06:28: Configuration unchanged, skipping qmake step.
09:06:28: Starting: "/usr/bin/make"
g++ -c -pipe -g -Wall -W -D_REENTRANT -fPIE -DQT_QML_DEBUG -DQT_DECLARATIVE_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I../../Qt/5.2.0/gcc_64/mkspecs/linux-g++ -I../CallMonitoring -I../../Qt/5.2.0/gcc_64/include -I../../Qt/5.2.0/gcc_64/include/QtWidgets -I../../Qt/5.2.0/gcc_64/include/QtGui -I../../Qt/5.2.0/gcc_64/include/QtCore -I. -I. -I. -o mainwindow.o ../CallMonitoring/mainwindow.cpp
../CallMonitoring/mainwindow.cpp: In destructor 'virtual MainWindow::~MainWindow()':
../CallMonitoring/mainwindow.cpp:152:13: error: no matching function for call to 'MainWindow::close(int&)'
../CallMonitoring/mainwindow.cpp:152:13: note: candidate is:
In file included from ../../Qt/5.2.0/gcc_64/include/QtWidgets/qmainwindow.h:45:0,
from ../../Qt/5.2.0/gcc_64/include/QtWidgets/QMainWindow:1,
from ../CallMonitoring/mainwindow.h:4,
from ../CallMonitoring/mainwindow.cpp:1:
../../Qt/5.2.0/gcc_64/include/QtWidgets/qwidget.h:478:10: note: bool QWidget::close()
../../Qt/5.2.0/gcc_64/include/QtWidgets/qwidget.h:478:10: note: candidate expects 0 arguments, 1 provided
../CallMonitoring/mainwindow.cpp: In member function 'void MainWindow::PollModem()':
../CallMonitoring/mainwindow.cpp:369:13: warning: unused variable 'j' [-Wunused-variable]
make: *** [mainwindow.o] Error 1
09:06:29: The process "/usr/bin/make" exited with code 2.
Error while building/deploying project CallMonitoring (kit: Desktop Qt 5.2.0 GCC 64bit)
When executing step 'Make'
@
Here's the c++ source statements:
@
MainWindow::~MainWindow()
{
close(fd);
delete ui;
QApplication::exit();
}
@
Any thoughts on how to easily work around this?Thanks in advance.
-
Hi,
You should use std::close or also port that part to Qt using QFile.
Out of curiosity, why do you call QApplication::exit in your destructor ?
-
wrote on 16 Feb 2015, 02:05 last edited by
"You should use std::close or also port that part to Qt using QFile."
Tried that, it gives me a diagnostic saying that close is not a part of std.
"Out of curiosity, why do you call QApplication::exit in your destructor ?"
Just my inexperience with qt showing. When I would terminate the app, the gui would remain. Adding the exit fixed that.
Porting to QT using QFile, I would lose my non blocking reads via select.
-
Then:
@
::close(fd);
@ -
wrote on 17 Feb 2015, 03:40 last edited by
Thank you, SGaist, that worked great. I appreciate it.
-
You're welcome !
If I may, you should rather have that IO part encapsulated in an object so you could reuse it for both your GUI and CLI version without duplicating the code
-
wrote on 18 Feb 2015, 11:39 last edited by
The GUI version of the program uses a QTimer to check the serial port for caller id information every 100 millisecionds. The timer provides a very neat and clean means of doing that. The CLI version implements that via "setitimer" and a self written interrupt handler.
As a retired software engineer, I worked mainly in real time embedded systems which back then was primarily a c and assembler world. I got out before I got beyond the journeyman level as a c++ guy. Now I just write apps for my own use.
This particular program addresses the problem that I have with telephone solicitors. My plan is, once the GUI is up and running, to discard the CLI version.
Thank you again for your very clear and concise assistance.
-
You're welcome !
I'd keep the CLI and update it so it can still be used through e.g. ssh
-
wrote on 19 Feb 2015, 03:59 last edited by
Upon further reflection, you're definitely right about that.
1/9