[Development] QtRemoteObjects - POD types derive from QObject
roland.m.winklmeier at gmail.com
Mon Feb 16 19:25:19 CET 2015
a while ago the QtRemoteObjects project was started in the playground area.
I had followed the discussions closely, because I'm running a project
which has a perfect use case for QtRemoteObjects. I haven't had much time
to look into the details yet, but now I did.
In the absence of documentation, I have several questions.
Quick background: the *.rep file format seem to support two types - POD and
* Does POD types officially support composition? So can I define a POD type
and use it as a member of a following POD/class? My tests seem to confirm
my assumption, but I wanted to be sure.
* I was quite surprised to see POD types are deriving from QObject. I would
expect it to be a non-QObject class. Is this a requirement for
QtRemoteObjects or can I disable it? I have quite a lot classes which are
not derived from QObject, because they are used in value semantics
(actively copied, assigned etc). This contradicts the QObject policy to be
entities and not copyable. I was even more surprised to see the usage of
qRegisterMetaType with QObjects.
As already mentioned I have a lot value classes, which are already
registered with the Qt metatype system, provide QDataStream operators. So
if subclassing QObject would not be a requirement, what would I need to add
to handcraft the headers? I would bypass the repc tool completely and add
the missing parts by hand.
Btw. is there any kind of roadmap or design goal? Because I would love to
see this in Qt and I'm curious what is still missing or what I still can
expect. This would help me to evaluate whether I use it in my project or
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development