[Development] Signals/slots for class templates (Was: Evolving Qt's multithreading API)
olivier at woboq.com
Tue Mar 19 15:02:35 CET 2013
On Monday 18 March 2013 07:49:07 Thiago Macieira wrote:
> We are talking about it.
As the one who says "-2", you are the one who is supposed to state your
> Can you tell us more about the long-term plan?
At first, it is an experiment to see what we can do.
It can be used in applications code for internal classes.
Then we can see how we can do to have the generated code installed and
> What do you plan on documenting? What can people depend on?
Good point. The documentation is still missing.
> Will you make moc's output files respect source- and binary-compatibility?
Yes, this need changes.
We will have to split the generated file in two part. One that is included by
the header containing the QObject, and one that is just linked with the code
like the current code. Peter's patch already does that.
We will also have to see which symbol need to be exported and how to do that.
(Symbols like qt_meta_stringdata_XXX and qt_meta_data_XXX will have to be
We currently rely on the QMetaObject's revision to know at runtime which
version of moc was used. But in the case where some code stays inlined with
the application, we will have to consider that even newer metaobject may still
have an old qt_meta_call implementation.
Then the main question is weather this is all worth it? Do we want to support
It is perhaps not that useful. But there are some good use cases still. The
intemview-ng needed to work around it. QFutureWatcher as well.
One of the often heard criticism of moc is that it does not handle template
objects. I think it is worth trying.
Now the problem is that templates are mostly useful in libraries. And should
we support template object if we don't support them yet for libraries? I'd
say yes, it is better than nothing. And we can see if there is good use cases.
Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
More information about the Development