On Mittwoch, 2. März 2016 13:48:49 CET Ziller Eike wrote: > > On Mar 2, 2016, at 11:23 AM, Milian Wolff <milian.wo...@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.wo...@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.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
