Trying to get basic signals example working

[mrstephengross]

Hi there--I'm just now learning Qt, and am trying to get a basic signals program working. It compiles, but links unsuccessfully (the compiler complains about the virtual table). I built the program with the standard qmake -project, qmake, make instructions. Does anyone have any ideas on this?

Here's the code, followed by the compiler output:

#include <QtCore/QObject>
 #include <iostream>
 
 class Go : public QObject
 {
     Q_OBJECT
 
 public:
 
     Go() { ; }
 
     ~Go() { ; }
 
     void go()
     {
         std::cout << "Emitting signal..." << std::endl;
         emit emit_signal();
     }
 
 public slots:
     void receive_signal()
     {
         std::cout << "Received signal!" << std::endl;
     }
 
 signals:
     void emit_signal() { }
 
 };
 
 int main()
 {
     Go g1, g2;
 
     QObject::connect(&g1, SIGNAL (emit_signal    ()),
                      &g2, SLOT   (receive_signal ()));
 
     g1.go();
 
     return 0;
 }

#include <QtCore/QObject>
 #include <iostream>

 class Go : public QObject
 {
     Q_OBJECT

 public:

     Go() { ; }

     ~Go() { ; }

     void go()
     {
         std::cout << "Emitting signal..." << std::endl;
         emit emit_signal();
     }

 public slots:
     void receive_signal()
     {
         std::cout << "Received signal!" << std::endl;
     }

 signals:
     void emit_signal() { }

 };

 int main()
 {
     Go g1, g2;

     QObject::connect(&g1, SIGNAL (emit_signal    ()),
                      &g2, SLOT   (receive_signal ()));

     g1.go();

     return 0;
 }

To copy to clipboard, switch view to plain text mode 

[Compiler output]
g++ -c -pipe -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/qt/mkspecs/linux-g++ -I. -I/usr/local/qt42/include/QtCore -I/usr/local/qt42/include/QtCore -I/usr/local/qt42/include/QtGui -I/usr/local/qt42/include/QtGui -I/usr/local/qt42/include -I. -I. -I. -o qtest.o qtest.C
g++ -o qtest qtest.o -L/usr/local/qt42/lib -lQtGui -L/usr/local/qt/lib -L/usr/X11R6/lib -lpng -lSM -lICE -lXrender -lXrandr -lXfixes -lXcursor -lXinerama -lfreetype -lfontconfig -lXext -lX11 -lQtCore -lz -lm -lglib-2.0 -ldl -lpthread
qtest.o(.text+0x24): In function `main':
: undefined reference to `vtable for Go'
qtest.o(.text+0x43): In function `main':
: undefined reference to `vtable for Go'
qtest.o(.text+0x6a): In function `main':
: undefined reference to `vtable for Go'
qtest.o(.text+0x7c): In function `main':
: undefined reference to `vtable for Go'
qtest.o(.text+0x9d): In function `main':
: undefined reference to `vtable for Go'
qtest.o(.text+0xb0): more undefined references to `vtable for Go' follow
collect2: ld returned 1 exit status
make: *** [qtest] Error 1

Thanks!
--Steve (sgross@sjm.com)

[jpn]

Hi,

Q_OBJECT macro works flawlessly in header files, but needs a little trick when added into a source file:

1. please rename qtest.C -> qtest.cpp (I've seen people having problems with the ".c" extension)
2. add #include "qtext.moc" at the end of the qtest.cpp
3. re-run qmake -project, qmake and make

Usually "qmake -project" is run only once in the beginning to create an initial project file. In this case it can be done again because there is only one file and it has been renamed. "qmake" needs to be re-run always after adding Q_OBJECT macro(s).

[smacchia]

Actually, I use .C extension all the time. And when I have seen this, I've cleared it by re-running qmake, then make. This seems to put in all the necessary moc creation into the makefile. I never have to include *.moc in my sources, rather they get linked in instead.

HTH,
Susan

[jpn]

Actually, I use .C extension all the time.

I'm not exactly sure if this has just been a problem in the past and already corrected. But I'm certainly sure that there have been many people for whom qmake failed to create correct makefiles, because of the extension.

And when I have seen this, I've cleared it by re-running qmake, then make. This seems to put in all the necessary moc creation into the makefile. I never have to include *.moc in my sources, rather they get linked in instead.

Yes, there is no problem when the macro is in a header file and the header is listed in .pro file. Furthermore, the "vtable" problem has nothing to do with the file extension. I was just assuring the correct behavior of the tools because I've seen it fail with such extension so many times.

Edit: Heh, how embarrassing. I didn't remember that the problem was so simple. A filename having ".c" as an extension gets compiled with gcc instead of g++. However, this is not the case with the uppercase version ".C", so there's no problem. Just for your information..

[smacchia]

Not surprising on .c vs. .C

And on embarrasing - been there, done that

On this problem, I had to see it 2-3 times over the course of development before it stuck how to fix it (i.e., qmake, then make)...talk about feeling embarrassed

[jacek]

I'm not exactly sure if this has just been a problem in the past and already corrected.

AFAIR Borland compiler didn't like any extension other than .cpp.