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.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? Thanks -- 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