What one line in QMetaType docs means?

qwe3

Hi,

I read about QMetaType and about qRegisterMetaType().

I don't undestand this:

After a type has been registered, you can create and destroy objects of that type dynamically at run-time.

I don't need to register my type to do something like:

void someClass::someButtonClickedSlot()
{
     myCustomClass * abc = new myCustomClass;
     ......
     delete abc;
}

Above I create object of type myCustomClass at run-time and destroy it. So what qRegisterMetaType() changed?

mrjj

@qwe3
Its its a bit odd worded. Clearly it works without. (for direct/normal use )

"Adding a Q_DECLARE_METATYPE() makes the type known to all template based functions, including QVariant. Note that if you intend to use the type in queued signal and slot connections or in QObject's property system, you also have to call qRegisterMetaType() since the names are resolved at runtime."

So Q_DECLARE_METATYPE makes it work with QVariant

qRegisterMetaType makes it possible to use with QueuedConnection

mrjj

Hi
It allows your TYPE/class to be used in signals and with Qt meta system.
It makes it known to Qt so to speak.
It has nothing to do with new and delete as such but allows Qt to handle your type
in various cases.

qwe3

@mrjj But what means "to be used in signals"?

When I have in some class:

connect(this, &someClass::signalWithMyCustomClassObject, this, &someClass:slotWithMyCustomClassObject);

I can send and receive my object and I don't used Q_DECLARE_METATYPE(myCustomClass) and I don't used qRegisterMetaType(). So why I can add myCustomClassObject as param to signal without this MACRO and function?

mrjj

@qwe3
hi
When signals are emitted in the same thread its like a function call and hence Qt needs not make copy of your Class (used as a parameter)
However, if you use the QueuedConnection

https://doc.qt.io/qt-5/qt.html#ConnectionType-enum

to say talk cross-thread, then Qt needs to know you type so it can make a copy to keep in the que.

This only applies if the paramter is not of pointer type as then it just copy the pointer. But when parameter is the concrete Type.

qwe3

@mrjj Thank you for answer, but I don't understand it.

I read this one:

https://doc.qt.io/qt-5/custom-types.html

The Q_DECLARE_METATYPE() macro also makes it possible for these values to be used as arguments to signals, but only in direct signal-slot connections.

Ok, I understand that, when I would like to use QueuedConnection I have to add qRegisterMetaType. But I would like only to use only one thread.

So:
If I don't add Q_DECLARE_METATYPE(myCustomClass) in myCustomClass I can used signal-slot direct connections, but QT will copy my class. So this is waste memory.

If I add Q_DECLARE_METATYPE(myCustomClass) in myCustomClass I can used signal-slot direct connections, and QT don't copy my class and I don't waste memory.

Am I right?

mrjj

@qwe3
Hi
Its more like. If you use QueuedConnection, Qt must be able to copy it. ( to put in on the event queue, versus it just calls directly )
Else it will just work without any of the macros.
Qt is smart enough to see its same thread and hence it just works.

qwe3

@mrjj But I don't see a problem in direct signal-slot connections. For me this is ordinary that I can add my own types as params to functions. And for me signals and slots are very simillar to functions. So why QT have to be smart to see that is the same thread? Is this a problem for QT that I add myOwnClassObject as params in signals?

EDIT: Look this @mrjj
https://stackoverflow.com/questions/39958267/qt-when-shall-i-use-q-declare-metatype/39958965
And comments to first ( started ) post

mrjj

@qwe3
There is no problem with direct connections as it just becomes
a function call.
However, if you add QueuedConnection to the connect then suddenly it must be able to
copy your type when a non pointer parameter.

Yes that link also explain it good.
So only when its QueuedConnection, Qt need to stuff that into a QVariant and then the macros are needed.

qwe3

@mrjj So there is a "bug" in this article?

https://doc.qt.io/qt-5/custom-types.html

There is information about direct signal-slots connections in section about Q_DECLARE_METATYPE(). And in the end of this section there is information that if you need to use QueuedConnection you have to add qRegisterMetaType() too.

So for me that information in Q_DECLARE_METATYPE() section:

The Q_DECLARE_METATYPE() macro also makes it possible for these values to be used as arguments to signals, but only in direct signal-slot connections.

is wrong.

mrjj

@qwe3
Its its a bit odd worded. Clearly it works without. (for direct/normal use )

"Adding a Q_DECLARE_METATYPE() makes the type known to all template based functions, including QVariant. Note that if you intend to use the type in queued signal and slot connections or in QObject's property system, you also have to call qRegisterMetaType() since the names are resolved at runtime."

So Q_DECLARE_METATYPE makes it work with QVariant

qRegisterMetaType makes it possible to use with QueuedConnection