> 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.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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
