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

[Ziller Eike]

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

-- 
Eike Ziller, Principle Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B