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.
Related
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!
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 reading other people's code and see this:
class UAVItem:public QObject,public QGraphicsItem
{
Q_OBJECT
Q_INTERFACES(QGraphicsItem)
...
But I didn't see they are using any sort of plug-in in this program.
Therefore, can I just remove the line:
Q_INTERFACES(QGraphicsItem)
?
If you have a class Derived which inherits from a class Base, which in turn inherits from QObject, and both Derived and Base contain the Q_OBJECT macro, then qobject_cast can be used to safely cast from a pointer (or reference) to Base, to a pointer (or reference) to Derived, similar to dynamic_cast in standard C++ but without RTTI.
If Base does not inherit from QObject, then qobject_cast can still be used in this way, but only if Base has a corresponding Q_DECLARE_INTERFACE macro and Derived contains Q_INTERFACES(Base).
In your case, Q_INTERFACES(QGraphicsItem) being present in UAVItem means that qobject_cast can be used to cast from a pointer (or reference) to QGraphicsItem to a pointer (or reference) to UAVItem, despite QGraphicsItem not inheriting from QObject.
From reference doc,
class ToolInterface
{
public:
virtual QString toolName() const = 0;
};
Q_DECLARE_INTERFACE(ToolInterface, "in.forwardbias.tool/1.0");
// Hammer in hammer.h (our Hammer plugin)
#include "toolinterface.h"
class Hammer : public QObject, public ToolInterface
{
Q_OBJECT
Q_INTERFACES(ToolInterface)
public:
QString toolName() const { return "hammer"; }
};
Q_EXPORT_PLUGIN2(hammer, Hammer);
When moc runs on the hammer.h code, it inspects Q_INTERFACES. It
generates code for a function called qt_metacall - void
*Hammer::qt_metacast(const char *iname). This goal of this 'casting' function is to return a pointer to an interface depending on iname.
moc also verifies whether the interface names that you have put inside
Q_INTERFACES have indeed been declared. It can do this by inspecting
the header files and looking for a Q_DECLARE_INTERFACE. In our case,
there is a Q_DECLARE_INTERFACE inside toolinterface.h.
According to http://qt-project.org/doc/qt-4.8/moc.html#multiple-inheritance-requires-qobject-to-be-first the QObject must be the first in the base classes when using multiple inheritance.
Is this because of some limitation in the moc tool or C++ memory layout problems are taken into consideration too, thus this restriction came into existence?
Assume that we have a class Test declared as:
class Test : public Foo, public QObject
{
Q_OBJECT
[..]
};
If you take a look at the moc_test.cpp file that the moc tool has generated, you will see something like:
[..]
const QMetaObject Command::staticMetaObject = {
{ &Foo::staticMetaObject, qt_meta_stringdata_Command,
qt_meta_data_Command, &staticMetaObjectExtraData }
};
[..]
Compiler will complain about staticMetaObject not being the member of Foo, as Foo is not a QObject. For some reason the moc tool generates this code taking the first parent class. Thus if you declare Test as:
class Test : public QObject, public Foo {};
The generated code will look fine to compiler.
I think this is made just for convenience because moc tool will hardly know which of the parent classes is a QObject without parsing the whole hierarchy.
Note: If you don't use the Q_OBJECT macro, you can derive your class from others in any order.
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.