I wanted to create a class in an separate file in Qt and then use this class in my main file (Background: Secondary thread updating GUI). Thus I wrote ReadDPC.h-file:
class ReadDPC: public QThread
{
//First edit:
Q_OBJECT
//End of first edit
public:
void run();
signals:
void currentCount(int);
};
And in my ReadDPC.cpp-file:
void ReadDPC::run()
{
while(1)
{
usleep(50);
int counts = read_DPC();
emit currentCount(counts);
}
}
read_DPC() is a function returning an int-value also placed in the cpp-file.
But when I want to compile this, I get the error undefined reference to ReadDPC::currentCount(int). Why? How can I solve this?
Edit: Added Q_Object-Macro, no solution.
Add Q_OBJECT macro to your subclass and run qmake.
This macro allows you use signals and slots mechanism. Without this macro moc can't create your signal so you get error that your signal is not exist.
Code should be:
class ReadDPC: public QThread {
Q_OBJECT
Note that when you use new signal and slot syntax, you can get compile time error that you forgot add this macro. If it is interesting for you, read more here: http://qt-project.org/wiki/New_Signal_Slot_Syntax
add Q_OBJECT
Clear your project
Run qmake
And only after that, run your project
When you are going to use Qt signals & slots mechanism you have to add Q_OBJECT macro in the top of definition of your class in order to generate correct moc_ code.
Why is this so?
The Meta-Object Compiler, moc, is the program that handles Qt's C++
extensions.
The moc tool reads a C++ header file. If it finds one or more class
declarations that contain the Q_OBJECT macro, it produces a C++ source
file containing the meta-object code for those classes. Among other
things, meta-object code is required for the signals and slots
mechanism, the run-time type information, and the dynamic property
system.
http://qt-project.org/doc/qt-4.8/moc.html#moc
Related
Is there a way in C++ to design a function / add some "attributes" to it in such a way that calling it several times in the code would raise a compile time error?
To give a bit of background / motivation: I was programming on Mbed-OS and I did a couple of mistakes that look like:
rtos::Thread thread;
[lots of code]
thread.start(persistent_function_1);
[lots of code in a setup function]
thread.start(persistent_function_2);
This had the (logical) consequence that the persistent_function_1, which should have been allowed to execute for the lifetime of the program, only got to execute until the thread was re-purposed to run persistent_function_2. It took me a long time to find this bug, and I was wondering if I can do something to my thread.start function to make sure I get a compiler error if I make this sort of mistake again.
I don't think there is a way to coerce the C++ language directly to detect double invocation of start() at compile time (put differently, I don't think #user4581301's suggestion would work): to statically assert a property you'd need to somehow change the entity. I'm sure you could write a custom checker using clang but I guess that isn't what you are after. It would, obviously, be possible to have a run-time assertion which reports that an already start()ed thread is started again. Again, that doesn't seem to be what you are after.
The "obvious" solution is no to have "[lots of code]" in a function to start with. In fact, std::thread entirely side-steps that issue by enforcing that there is no code between the object declaration and its start: the std::thread is started upon construction. The setup with "[lots of code]" between the object declaration and the start would be something like
my::thread thread([&]{
[lots of code]
return persistent_function_1;
}());
The caveat is that you'd need to set up your various variables sort of out of order. That is, the preferred approach would be to declare the thread object at the site where it is actually started:
[lots of code]
my::thread thread(persistent_function_1);
In both of these cases my::thread would be a trivial wrapper around rtos::thread which doesn't expose a separate start() method. As I don't know why rtos::thread separates construction and start() and a plausible reason could be the ability to set up various thread parameters, it may be reasonable to actually use two separate arguments to my::thread's constructor:
A function taking a my::thread::properties entity as parameter which allows the necessary manipulations of the thread object.
The function to be started.
That is, something like
my::thread thread([](my::thread::properties& properties) {
[lots of code manipulating the properties]
},
persistent_function_1);
This way, it remains possible to manipulate the thread but you can't possible start() a thread twice.
One option is to wrap the thread in a new manager object, with the rough shape of
class thread_manager {
rtos::Thread thread;
const std::function<...> execution_function;
/* .
.
. */
public:
thread_manager(rtos::Thread _thread, std::function<...> function, ...)
: thread { _thread }
, execution_function { function }
, ...
void start();
}
and disallowing any other usage of threading (which can be justified on the basis of encapsulation, although as pointed out in comments, yahoos are always a risk).
There is no current mechanism for detecting an expression that appears twice. But you can torture the compiler to get something close
namespace
{
template<int>
struct once
{
once() {}
friend void redefine() {}
};
}
#define ONCE(expr) (once<__COUNTER__>{}, (expr))
If ONCE ever appear twice in the same TU, the compiler will complain about redefining redefine.
ONCE(thread.start(persistent_function_1)); // ok
ONCE(thread.start(persistent_function_2)); // error
In the Qt documentation on menus, they show how to override the Context Menu for a widget. They use the macro QT_NO_CONTEXTMENU, but they don't make any comments in the text about this macro, why it's there, or who uses it:
#ifndef QT_NO_CONTEXTMENU
void contextMenuEvent(QContextMenuEvent *event) override;
#endif // QT_NO_CONTEXTMENU
When is QT_NO_CONTEXTMENU defined by Qt?
I could see Qt defining this macro for you on systems that don't support context menus, for example. Since QAbstractScrollAreas declaration of contextMenuEvent is wrapped in this same way, I know I must use the macro as well to be safe, otherwise I risk using override on a non-existent function that would never get called. But I want to know what would cause this macro to be defined in the first place, since it seems very odd to me that this would be a macro in the first place, rather than a member variable of QAbstractScrollArea that can be set at any time.
This macro gets defined when the -no-feature-CONTEXTMENU option is set when configuring and building Qt from source, i.e. using the configure tool. You are correct that it's for systems that don't support context menus. These are usually embedded systems (e.g. touch-screen kiosk) that have limited resources so you don't want to bog them down with any extra modules, especially ones that won't be used anyway.
I have a C++ framework being built in the latest version of Xcode (9.4.1 at the time of writing) that I am using from Objective-C++ code, again within Xcode. I need to perform a dynamic_cast from one pointer type to another. However, the dynamic_cast is only working from a Debug build and is not working from a Release build. Is there something I'm missing or understanding about how dynamic_cast works here within Objective-C++ that makes this sample fail?
C++ Framework
TestClass.hpp
class Parent {
public:
// https://stackoverflow.com/a/8470002/3938401
// must have at least 1 virtual function for RTTI
virtual ~Parent();
Parent() {}
};
class Child : public Parent {
public:
// if you put the implementation for this func
// in the header, everything works.
static Child* createRawPtr();
};
TestClass.cpp
#include "TestClass.hpp"
Parent::~Parent() {}
Child* Child::createRawPtr() {
return new Child;
}
Objective-C++ Command Line App
main.mm
#import <Foundation/Foundation.h>
#import <TestCastCPP/TestClass.hpp>
int main(int argc, const char * argv[]) {
#autoreleasepool {
Parent *parentPtr = Child::createRawPtr();
Child *child = dynamic_cast<Child*>(parentPtr);
NSLog(#"Was the cast successful? %s", child != nullptr ? "True" : "False");
}
return 0;
}
In both Debug and Release, I expect this code to print "True". However, in reality, Release mode prints "False". As a smoke test, the dynamic_cast at this SO post works just fine.
Interestingly, the same sort of code works from a C++ command line application, again within Xcode. I have tried disabling the optimizer in Release mode, but this did not seem to fix the problem.
I have a sample project up on GitHub here. Remember to compile it in Release to see the reason for my question. I've included the TestCast scheme for Objective-C++, and the TestCastCPP scheme for the straight C++.
It is hard to know the compiler specifics, since how a compiler does RTTI has some flexibility (i.e., not specified in great detail by the specification).
In this case, since Child class did not have any virtual functions defined, I suspect the compiler had emitted RTTI with every translation unit for the Child class.
When the framework was linked, and when the executable was linked, each had their own Child RTTI information, since each translation unit emitted its own RTTI.
The Parent link of the one did not match the Parent link of the other, I suspect, so they did not have the same Parent pointer and those things were not "fixed up" by the dynamic loader. (The dynamic_cast<Child*> basically walks the parent pointer chain until it finds a match by pointer value, not by RTTI value.)
If you looked at nm -g TestCast | c++filt dumps of the app and of the framework, you can see the RTTI blocks. Disassembling them, I think the Child RTTI was already resolved in both situations to their own Parent RTTI.
Why did it work for DEBUG, but not RELEASE? Probably, one of the release optimizations was dead-code stripping of external linkage symbols based on usage. So the dynamic loader (dyld) for DEBUG was able to resolve the symbols, but the RELEASE build one-or-more symbols was already internally resolved.
There's probably a way to indicate an "unused" symbol for the RTTI should be retained and exported, which will vary by compiler/linker. But that's more bother than providing an explicit "first virtual function" (such as the virtual Child destructor) which avoids the problem.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Undefined reference to vtable. Trying to compile a Qt project
here is the code
#include <iostream>
#include <QApplication>
#include <QTimer>
class myClass : public QObject {
Q_OBJECT
public:
QTimer *timer;
myClass(){
timer = new QTimer(this);
connect(timer, SIGNAL(timeout()), this, SLOT(mySlot()));
timer->start(1000);
}
public slots:
void mySlot() {
std::cout << "Fire" << std::endl;
}
};
int main() {
std::cout << "Hello, world";
myClass atimer;
return 0;
}
Apart from the error, there are two more things I don't understand:
Why there isn't any semicolon after macros, in this case Q_OBJECT. It doesn't seem to obey C++ syntax but yet people write code like that.
The "public slots" is a modifier created by Qt, but how come gcc compiler can still understand it. How could an IDE like Qt modify the standard syntax of a language?
You didn't give the exact error message, but I suspect what's happening is that you didn't run moc on your code, or you didn't compile the code generated by moc, or you didn't link the code into your executable/library.
As for your other questions:
You don't need to have a semicolon after macros; the preprocessor doesn't care about semicolons - only the compiler does. So whether or not you need to add a semicolon manually depends on what your macro (Q_OBJECT) in this case expands to, and where you use it. In your case, no semicolon is needed.
slots is an macro which expands to an emtpy string, so any C++ compile can process it. However, slots is also recognized as a special key word by moc. The same goes for signals, by the way (it's a macro expanding to protected:).
This is just because you didn't run qmake since you aded Q_OBJECT. Just run qmake (if you use QtCreator, it must be in the Build Menu) and then compile ;).
Hope it helped
Usually an undefined reference to vtable indicates that you declared some virtual functions, but never provide the definition to them. Perhaps Q_OBJECT is declaring something?
Macros are expanded before C++ syntax is considered, working in textual form. That is why macros themselves do not have to obey C++ syntax. If, for example, Q_OBJECT contains a semicolon at the end of its definition, so that after the substitution you get a correct C++ code, then that is good enough.
slots may be a macro as well (maybe even an empty one). Then, after substituting slots with nothingness you get a valid C++ code again.
You have to use the Meta Object Compiler delivered by QT
In general if you're getting an undefined reference to vtable error it's because qmake hasn't ran and generated a necessary moc for it. Rerunning qmake in the project directory should fix it, if it doesn't then clean the build and run quake and make again.
the context
I'm working on a project having some "modules".
What I call a module here is a simple class, implementing a particular functionality and derivating from an abstract class GenericModule which force an interface.
New modules are supposed to be added in the future.
Several instances of a module can be loaded at the same time, or none, depending on the configuration file.
I though it would be great if a future developer could just "register" his module with the system in a simple line. More or less the same way they register tests in google test.
the context² (technical)
I'm building the project with visual studio 2005.
The code is entirely in a library, except the main() which is in an exec project.
I'd like to keep it that way.
my solution
I found inspiration in what they did with google test.
I created a templated Factory. which looks more or less like this (I've skipped uninteresting parts to keep this question somewhat readable ):
class CModuleFactory : boost::noncopyable
{
public:
virtual ~CModuleFactory() {};
virtual CModuleGenerique* operator()(
const boost::property_tree::ptree& rParametres ) const = 0;
};
template <class T>
class CModuleFactoryImpl : public CModuleFactory
{
public:
CModuleGenerique* operator()(
const boost::property_tree::ptree& rParametres ) const
{
return new T( rParametres );
}
};
and a method supposed to register the module and add it's factory to a list.
class CGenericModule
{
// ...
template <class T>
static int declareModule( const std::string& rstrModuleName )
{
// creation de la factory
CModuleFactoryImpl<T>* pFactory = new CModuleFactoryImpl<T>();
// adds the factory to a map of "id" => factory
CAcquisition::s_mapModuleFactory()[rstrModuleName ] = pFactory;
return 0;
}
};
now in a module all I need to do to declare a module is :
static int initModule =
acquisition::CGenericModule::declareModule<acquisition::modules::CMyMod>(
"mod_name"
);
( in the future it'll be wrapped in a macro allowing to do
DECLARE_MODULE( "mod_name", acquisition::modules::CMyMod );
)
the problem
Allright now the problem.
The thing is, it does work, but not exactly the way i'd want.
The method declareModule is not being called if I put the definition of the initModule in the .cpp of the module (where I'd like to have it) (or even in the .h).
If I put the static init in a used .cpp file .. it works.
By used I mean : having code being called elsewhere.
The thing is visual studio seems to discard the entire obj when building the library. I guess that's because it's not being used anywhere.
I activated verbose linking and in pass n°2 it lists the .objs in the library and the .obj of the module isn't there.
almost resolved?
I found this and tried to add the /OPT:NOREF option but it didn't work.
I didn't try to put a function in the .h of the module and call it from elsewhere, because the whole point is being able to declare it in one line in it's file.
Also I think the problem is similar to this one but the solution is for g++ not visual :'(
edit: I just read the note in the answer to this question. Well if I #include the .h of the module from an other .cpp, and put the init in the module's .h. It works and the initialization is actually done twice ... once in each compilation unit? well it seems it happens in the module's compilation unit ...
side notes
Please if you don't agree with what I'm trying to do, fell free to tell, but I'm still interested in a solution
If you want this kind of self-registering behavior in your "modules", your assumption that the linker is optimizing out initModule because it is not directly referenced may be incorrect (though it could also be correct :-).
When you register these modules, are you modifying another static variable defined at file scope? If so, you at least have an initialization order problem. This could even manifest itself only in release builds (initialization order can vary depending on compiler settings) which might lead you to believe that the linker is optimizing out this initModule variable even though it may not be doing so.
The module registry kind of variable (be it a list of registrants or whatever it is) should be lazy constructed if you want to do things this way. Example:
static vector<string> unsafe_static; // bad
vector<string>& safe_static()
{
static vector<string> f;
return f;
} // ok
Note that the above has problems with concurrency. Some thread synchronization is needed for multiple threads calling safe_static.
I suspect your real problem has to do with initialization order even though it may appear that the initModule definition is being excluded by the linker. Typically linkers don't omit references which have side effects.
If you find out for a fact that it's not an initialization order problem and that the code is being omitted by the linker, then one way to force it is to export initModule (ex: dllexport on MSVC). You should think carefully if this kind of self-registration behavior really outweighs the simple process of adding on to a list of function calls to initialize your "modules". You could also achieve this more naturally if each "module" was defined in a separate shared library/DLL, in which case your macro could just be defining the function to export which can be added automatically by the host application. Of course that carries the burden of having to define a separate project for each "module" you create as opposed to just adding a self-registering cpp file to an existing project.
I've got something similar based on the code from wxWidgets, however I've only ever used it as a DLL. The wxWidgets code works with static libs however.
The bit that might make a difference is that in wx the equivelant of the following is defined at class scope.
static int initModule =
acquisition::CGenericModule::declareModule<acquisition::modules::CMyMod>(
"mod_name"
);
Something like the following where the creation of the Factory because it is static causes it to be loaded to the Factory list.
#define DECLARE_CLASS(name)\
class name: public Interface { \
private: \
static Factory m_reg;\
static std::auto_ptr<Interface > clone();
#define IMPLEMENT_IAUTH(name,method)\
Factory name::m_reg(method,name::clone);\