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

[Milian Wolff]

On Mittwoch, 2. März 2016 13:48:49 CET Ziller Eike wrote:
> > On Mar 2, 2016, at 11:23 AM, Milian Wolff <milian.wolff at kdab.com> wrote:
> > 
> > On Mittwoch, 2. März 2016 10:14:18 CET Ziller Eike wrote:
> > 
> >>> On Feb 29, 2016, at 1:21 PM, Milian Wolff <milian.wolff at kdab.com>
> >>> wrote:
> >>> 
> >>> 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.h
> >>>>>> tm
> >>>>>> l
> >>>>>> 
> >>>>>> 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>;
> >> 
> >> 
> >> 
> >> That would break if any other code in the application (possibly in a
> >> different library linked to it) has e.g.
> > 
> > using Blah = Foo<int>;
> > 
> >> right?
> >> That sounds pretty fragile. Especially if an application loads plugins.
> > 
> > 
> > Can you clarify what would break here? Isn't it exactly the same as doing
> > 
> > QVector<int> in multiple TUs?
> 
> 
> As I understood it, moc would generate the MetaObject for Foo<int> when it
> sees “using SomeAlias = Foo<int>” (or some macro).
 So if lib A does it and
> lib B does it, and they both get linked into the same application, there
> would be two implementations of the static meta object, which Thiago said
> would not work? But maybe I missed something from the discussion.

Ah, indeed - QMetaObject::cast e.g. does a pointer comparison on the static 
meta object. So if we end up with two instances of that in different TUs, 
we'll encounter issues.

A simple solution would then be a macro for an explicit instantiation, similar 
to what we already do with Q_DECLARE_LOGGING_CATEGORY/Q_LOGGING_CATEGORY. Only 
there then would moc generate the static meta object. That should work, no?

Bye
-- 
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/20160302/f673db44/attachment.bin>