[Development] QtRemoteObjects - POD types derive from QObject

Roland Winklmeier roland.m.winklmeier at gmail.com
Mon Feb 16 19:25:19 CET 2015


Dear list,

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
class.

* 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
not.

Best regards,
Roland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150216/c9a25c69/attachment.html>


More information about the Development mailing list