[Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Milian Wolff]

On Friday, February 26, 2016 3:56:08 PM CET Thiago Macieira wrote:
> On sexta-feira, 26 de fevereiro de 2016 20:30:28 PST Milian Wolff wrote:
> > >  The main problems of templated QObject are captured more or less in
> > >  this
> > > 
> > > thread:
> > > http://lists.qt-project.org/pipermail/development/2013-March/010288.html
> > > 
> > >  Personally I still think it would be a fancy feature, a bit dangerous
> > >  to
> > > 
> > > implement maybe even dangerous to use, but really cool :-D
> > 
> > Thanks for the link. How often is the MOC layout changed in an ABI
> > incompatible way?
> 
> There's no historical pattern. There was a major break from Qt 3 to 4 and
> smaller one from 4 to 5. Qt 4 did have updates that didn't break the ABI;
> the Qt 5.0 update removed the ability to read meta objects created with Qt
> 4 moc. I don't remember how the 1→2 and 2→3 updates happened (Qt 3 still
> used register-on-load meta objects).
>
> But since the meta object itself has a version number and the only code that
> ever reads the internal data is inside QtCore, so we could make changes
> that change the layout.  We haven't done that: all changes between major
> releases have added things without changing the layout.
> 
> That's the structure layout though. The file itself compares the
> Q_MOC_OUTPUT_REVISION macro for equality (not ordering).

OK, but changing the layout between major versions is fine as we break ABI 
anyways then, no?
 
> > I.e. what problems would we get from having to install the
> > moc files?
> 
> Lots.

<snip>

> Have I convinced you? I'm only getting warmed up. I'm sure I can find more
> issues.

Thanks for the exhaustive, and educative list! I think this should be put on 
the Wiki somewhere for future reference.
 
> > Alternatively: couldn't moc re-create the required data from included
> > files
> > when they contain templated objects? That would solve the problem as well,
> > no?
> 
> I have no idea what you meant here.
> 
> Or, well, I do have one, but I don't think that I understood correctly what
> you're suggesting. I understood that we keep a copy of the header file's
> source in the target application and run moc at runtime to dynamically
> create the meta object, on the fly.
> 
> Since I don't think that's what you're suggesting and since the above has so
> many problems (starting with the fact that it doesn't resolve the problem),
> I'm not even going to analyse it.
> 
> Can you clarify what you meant?

Yes, what I had in mind from my outsiders POV was the following, and I have no 
clue whether it is feasible at all:

We have the following structure:

$path1/lib/foo.h
template<typename T> Foo : QObject { ...};

moc is not doing anything here as the templated QObject is not fully 
specialized.

$path2/app/bar.h:
#include <some_templated_qobject.h>
using Bar = Foo<int>;

Now when we compile app, moc runs over the fully specialized templated QObject 
and can instantiate it as needed and put all the required code into the 
moc_bar.cpp file as it would for a "normal" QObject. I.e. there is no need to 
install the templated QObject's moc file. This also is close to how an 
ordinary template is handled by a C++ compiler as far as I know.

Maybe I'm missing something, but this sounds like an elegant solution? The 
only downside is increased complexity in moc to find such instantiations. 
Until clang can be used for moc, we could add a macro, lets say 
Q_INSTANTIATE(Foo<int>), or similar.

What do you say? What am I missing that would break my assumptions?
-- 
Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5903 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160229/479abbcf/attachment.bin>