I'm working on my first non-trivial project using the Qt Framework and to help maintain consistency across documents and to ensure I don't forget some small requirement I've decided to make a template document demonstrating the member functions, macros, etc. needed to subclass QObject. I also want to be able to fully utilize the Meta Object system. Am I missing anything or misunderstanding anything? Also feel free to give any general C++ critiques as necessary.
I'm especially concerned with the issue of whether or not to include a copy constructor. Is that only necessary for classes not derived from QObject?
Requirements (links are to the document I got the requirements from)
Public Default Constructor (link)
Public Copy Constructor (see 1) (but conflicts with this)
Public Destructor (see 1)
Use the Q_OBJECT Macro (link)
Ensure Properties Are Accessible with the Q_PROPERTY(...) Macro (link)
Declare the Type with Q_DECLARE_METATYPE(T) in the Header (link) (link)
Declare any Enums Used with Q_ENUM(E) in the Header (link)
Template Header
// Include guards
#ifndef CLASSNAME_H
#define CLASSNAME_H
// Include statements
#include <QObject>
#include <T.h>
// Enum definition
enum E{
E0,
E1,
E2
};
// Q_ENUM Macro
Q_ENUM(E)
// Class declaration
class ClassName : public QObject
{
// Q_OBJECT Macro
Q_OBJECT
// Q_PROPERTY Macros
Q_PROPERTY(T* memberA READ memberA WRITE setMemberA NOTIFY memberAChanged)
Q_PROPERTY(int memberB READ memberB WRITE setMemberB NOTIFY memberBChanged)
Q_PROPERTY(E memberC READ memberC WRITE setMemberC RESET resetMemberC)
public:
// Constructors and Destructor
ClassName(QObject *parent = nullptr);
ClassName() = default;
ClassName(const ClassName&) = default;
~ClassName();
// Getters
T* memberA() const {return m_memberA;}
int memberB() const {return m_memberB;}
E memberC() const {return m_memberC;}
// Setters
void setMemberA(T* newA);
void setMemberB(int newB);
void setMemberC(E newC);
signals:
void memberAChanged(T*);
void memberBChanged(int);
public slots:
void resetMemberC();
private slots:
private:
// Data Members
T* m_memberA;
int m_memberB;
E m_memberC;
};
// Meta Object Type Declaration
Q_DECLARE_METATYPE(TypeName);
// End include guard
#endif // CLASSNAME_H
The source file to accompany this header would likely be trivial, so I won't include it here. Though if anyone thinks it would be helpful to demonstrate some requirement or functionality, I'd be happy to write it out.
As Jeremy Friesner suggested, the requirements are not that strict. The situation is more like this:
If your class uses signals and/or slots, it must both have the Q_OBJECT macro and be derived from QObject,
If it only uses other meta-object functionality, such as Q_PROPERTY declarations, it can use the Q_GADGET macro and need not be derived from QObject,
If it doesn't need any of that, but should still be compatible with Qt templates like QVariant, it should be declared with Q_DECLARE_METATYPE. The same applies to enums and Q_ENUM.
A Q_PROPERTY/Q_INVOKABLE interface is only really needed if you need your class to be interoperable with QML code.
As for your other question, yes that is an important difference between QObjects and non-QObjects. The metatype must be copyable, which is why that is required of types you manually declare as metatypes, and also why the system instead uses pointers for QObject types, which are not copyable themselves. A minimal QObject declaration could start like this:
#ifndef CLASSNAME_H
#define CLASSNAME_H
#include <QObject>
// Enums in the global namespace cannot be registered; they must be enclosed
// in a class and registered with Q_ENUM, or in a namespace declared as
// Q_NAMESPACE and registered with Q_ENUM_NS
class ClassName : public QObject
{
Q_OBJECT
public:
// Default constructor, with explicit specifier to prevent accidental
// implicit conversion from a QObject*
explicit ClassName(QObject *parent = nullptr);
};
// ClassName* is automatically declared as a metatype
#endif // CLASSNAME_H
In general I'd recommend the "rule of zero": if possible, do not declare a destructor, nor any copy and move operations, and leave them to the compiler. Of course I also recommend all of the other guidelines there, if you have the time!
Related
I`m having the hardest time in creating a class+subclass using Q_OBJECT:
I have a class geometry and some classes Geo_1PF, Geo_2,.. that inherit from geometry. I created those classes an everything worked well. Now I want to use QMetaType and for that I need to declare Q_Object.
Once I used Q_OBJECT / Q_DECLARE_METATYPE my problems started.
I get the error "undefined reference to vtable for ..."
I tried to delete all .o and all moc_.cpp before compiling again. I added QT += core in the *.pro-File but I didn`t succeed.
Do I have to put Q_OBJECT / Q_DECLARE_METATYPE in both the parent and the cild class?
Why do I get that error ?
Can somebody help me please?
This is my code:
geometry.h:
#ifndef GEOMETRY_H
#define GEOMETRY_H
#include <QMetaType>
#include <QWidget>
#include <QObject>
#include <QDebug>
class Geometry
{
// Q_OBJECT
protected:
public:
Geometry();
virtual ~Geometry(void) {}
virtual void write_LNE();
//Q_DECLARE_METATYPE(Geometry);
#endif // GEOMETRY_H
-
geometry.cpp:
#include "geometry.h"
Geometry::Geometry()
{ qDebug() << "Constructor: hier ist Geometry"; }
void Geometry::Haupt()
{ qDebug() << " Das hier ist die Haupt von Geometry ....." ; }
void Geometry::write_LNE(){}
-
Geo_1PF.h:
#ifndef GEO_1PF_H
#define GEO_1PF_H
#include "geometry.h"
class Geo_1PF : public Geometry
{
// Q_OBJECT
public:
Geo_1PF();
~Geo_1PF() {}
virtual void write_LNE();
};
//Q_DECLARE_METATYPE(Geo_1PF);
#endif // GEO_1PF_H
Geo_1PF.cpp:
#include "Geo_1PF.h"
Geo_1PF::Geo_1PF()
{
}
If you want to use Q_OBJECT your class should inherites from QObject or its subclasses
class Geometry : public QObject
{
Q_OBJECT
//...
See Using the Meta-Object Compiler (moc)
First, the Q_OBJECT macro is not inheritable. It must be included in every object that directly or indirectly inherits QObject. If your base class is QObject derived, then your derived class is also QObject derived, and thus must include the macro.
From the documentation:
The Q_OBJECT macro must appear in the private section of a class
definition that declares its own signals and slots or that uses other
services provided by Qt's meta-object system.
Second, Q_DECLARE_METATYPE() requires that the object has a copy constructor, and QObject doesn't support copy constructors by design, so it is impossible to use Q_DECLARE_METATYPE() with a QObject derived class. And it doesn't make sense either, because every QObject is automatically a meta type, since it is being processed by the meta object compiler. It will work if you declare a pointer to your type - Q_DECLARE_METATYPE(Geometry*). Registering a type as a meta type requires the type to have a copy constructor, if it doesn't you get an error.
From the looks of your classes, they don't need to derive from QObject, so you should not do that, you should remove the macro (and never use it if you are not inheriting a QObject or derived), and then Q_DECLARE_METATYPE(Geometry) should work. It looks like you were under the impression you need Q_OBJECT to Q_DECLARE_METATYPE() but in reality it is the opposite - the two are incompatible - the latter must have and the former must not have a copy constructor.
I am trying to build a shared library with Qt 5.6.0 and i would like to use Pimpl.
I have one class to export and this class inherits from QGraphicsScene, which itself inherits from QObject :
// CustomScene.h
#include "customscene_global.h" // recommended header from Qt
#include <QGraphicsScene> // do not compile if not present
// forward declarations
class CustomSceneImpl;
template <typename T> class QList;
class QString;
template <class Key, class T> class QMap;
// some other classes ...
class CustomScene : public QGraphicsScene
{
Q_OBJECT
public :
// some public functions
signals:
// some custom signals
public slots:
// some custom public slots
private:
CustomSceneImpl *m_pimpl; // pointer to private members
};
Everything's is fine if i #include <QGraphicsScene> in this header but i would prefer to forward declare QGraphicsScene. However i get the following compile error if i do that :
error: invalid use of incomplete type 'struct QGraphicsScene'
I guess i am doing something wrong with the QObject Macro, that is not recognized, and with the moc in general.
I know there are dedicated Qt Macro to use Pimpl ( Q_D, .. ) but i did not really understand how to use them and if it would fix this issue.
Thanks for your help.
Everything's is fine if i #include QGraphicsScene in this header but i would prefer to forward declare QGraphicsScene.
you cannot do it as you inherit from QGraphicsScene:
class CustomScene : public QGraphicsScene
btw. this error has nothing to do with the way you implemented PIMPL idiom (actually it looks fine), inheritance from incomplete type is simply not possible as compiler needs to know the size / layout of your base class.
Since a forward declared class has no information about the content, you can't use it for inheritance.
You can use PIMPL idiom for composition, not for inheritance. If you need to inherit from QGraphicsScene, you cannot forward declare it. You have to include its full definition.
I am new at building distributable libraries written in C++ and I am getting a bit lost.
I have created a .cpp file with wrappers for all functions I want the library to offer users, and I have written 2 .h files, one public and one private. Below is a dummy example of my header files:
public.h:
class myclass
{
public:
public_function();
private:
}
private.h:
class myclass
{
public:
public_function();
private:
anotherClass instanceofClass;
}
Note that the implementation of public_function() uses the "instanceofClass" in the code.
I have been able to compile with no problem the code using the private class and to compile and link the library with external programs using the public header and the compiled library. When executing that code, though, I am getting segmentation faults that I suspect have to do with lack of proper initialization of "instanceofClass".
Am I doing the right thing? Am I forced to instantiate "instanceofClass" inside the implementation of public_function() for it to be initialized properly, or is there anything else I should do instead?
Thanks a lot.
You can't declare the same class 'myclass' in two different ways. There has to be a single class definition. If you want to hide the implementation's API you want to use the 'Pimpl' idiom. So your public class has a single pointer to a private class. For example:
public.h
class myclass_private;
class myclass {
private:
myclass_private* pimpl;
public:
myclass();
void public_function();
};
public.cpp
myclass::myclass() {
pimpl = new myclass_private;
}
void myclass::public_function() {
pimpl->private_function();
}
private.h
class myclass_private {
public:
void private_function();
};
The myclass defined in public.h has no members, and is therefore sized 1 byte. The myclass defined in private.h encapsulates anotherClass, and is therefore whatever size anotherClass is. This inconsistency is the root of your problem.
What you ought to do is have only one header, and use a pointer (which doesn't require a class definition) to enable hiding the implementation of anotherClass. I'll repeat Joachim's link to the pimpl idiom for elaboration.
The definition of a class shall not changr between different translation units. This is one of the aspects of the One Definition Rule. What you might want to donis to define the publicly visible class to have a pointer to a private implementation: the Pimpl Idiom:
class Public {
public:
...
private:
struct Impl;
Impl* impl_;
};
The struct Impl would only be defined in the implementation file.
Your class lacks a proper constructor, which means that the compiler will provide a default one based on the content of the class definition. If that definition isn't consistent accross all the code, it won't get initialized the same way everywhere, and some data may be missing.
If you want to hide the implementation details of instanceofClass, just do a forward declaration in the header (the private header you're providing is correct, you can use it as your public one), and provide an implementation somewhere in your code.
In an effort to optimize the binary of a Qt-based dynamic library, I'm attempting to selectively export a number of relevant methods from classes that inherit from QObject and use moc to define custom signals and slots, instead of exporting them entirely (all of their members). Some sample code is below.
#ifdef LIB_BUILD
#define LIB_SHARED Q_DECL_EXPORT
#else
#define LIB_SHARED Q_DECL_IMPORT
#endif
class C: public QObject {
Q_OBJECT
public:
LIB_SHARED void f();
/* ... */
public slots:
LIB_SHARED void g();
private:
void h();
private slots:
void i();
};
The idea: since h() and i() are private (and no inline method call any of these functions), there is no need to export these symbols, since they will be used by the library alone. On the other hand, f() and g() are members eligible for exporting, so they're explicitly marked for that.
The problem: the Q_OBJECT macro declares a couple of virtual method overrides for methods in QObject, and these methods are not exported (since the macro will expand to declarations not containing LIB_SHARED or Q_DECL_EXPORT). Thus, the virtual table will be incomplete in client code.
The (un)solution: apply LIB_SHARED to the entire class, as it is typically suggested:
class LIB_SHARED C: public QObject { /* ... */ };
This solves linking problems, but the primary goal (eliminating unnecessary export table entries) is not reached, at least not for QObject-based classes.
The question: is there any way to achieve the desired result? I've tried messing a bit around the Q_OBJECT macro, with no success.
I hope for a solution that works on Linux systems too (assuming hidden symbol visibility as default), so .def files are not applicable. Hacks, however, are welcome :)
Any help is appreciated.
PS: Note that besides this problem is framed in a Qt environment, it can happen anywhere where a macro expansion is used to generate declarations, as in this case.
Try to use pimpl idiom and export only public part. For example:
class CPrivate;
class LIB_SHARED C: public QObject {
Q_OBJECT
private:
CPrivate* m_private;
public:
...
};
And create private class where placed all private (non exportable) stuff:
class CPrivate : public QObject {
Q_OBJECT
public:
void h();
public slots:
void i();
}
Then initialize and call private implementation from public class.
I have a class that has some data members that I want to be hidden from the caller (because including the headers for their types significantly increases the compile time, and it would require every project using this class to add an additional path to their include paths).
This class uses QSharedDataPointer to store this data. This way it can be copied by using the default copy constructor.
The basic structure of this class is:
class MyClass {
private:
QSharedDataPointer<MySharedClassData> m_data;
};
Is there any fancy trick to do this without defining MySharedClassData (which inherits from QSharedData) in the same header file? Or is there any other good way of hiding data fields?
I've already tried a forward declaration of MySharedClassData but this didn't work (despite the fact that m_data is private).
The only solution I can currently thing of is to declare m_data as QSharedDataPointer<QSharedData> but then I need to cast the data member every time I want to access it. Is there a better solution?
The forward declaration should be working as long as you constructor and destructor are not defined in the header. The following class compiles on my computer:
#ifndef MAIN_WINDOW_HXX
#define MAIN_WINDOW_HXX
#include <QMainWindow>
#include <ui_MainWindow.h>
#include <QSharedDataPointer>
class MySharedClassData;
class MainWindow : public QMainWindow, private Ui_MainWindow {
Q_OBJECT
public:
explicit MainWindow(QWidget *parent = 0, Qt::WindowFlags flags = 0);
virtual ~MainWindow();
QSharedDataPointer<MySharedClassData> m_data;
};
#endif
If you try to inline your constructor/destructor, then you might receive a: C2027: use of undefined type 'type' under VS.
Yes. There's no really fancy trick required. However, all methods that do need MySharedClassData must be defined after the definition of MySharedClassData. If you move the class definition to a .cpp file, the methods have to be moved there too.
In general, if you want to use the pimpl idiom with a smart pointer to a forward-declared impl (rather than managing the impl object manually), you need a smart pointer with an out-of-line deleter, like boost::shared_ptr (you should be able to use std::unique_ptr with a custom deleter, but I haven't tried).
The requirement is that you can instantiate the smart pointer template without seeing the impl class destructor: this rules out std::auto_ptr for example.
I don't know whether QSharedDataPointer meets the requirement or not, but tibur seems to say it does.