> 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.html >>>> >>>> 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. Br, Eike > Now when we compile app, moc runs over the fully specialized templated > QObject > and can instantiate it as needed and put all the required code into the > moc_bar.cpp file as it would for a "normal" QObject. I.e. there is no need to > install the templated QObject's moc file. This also is close to how an > ordinary template is handled by a C++ compiler as far as I know. > > Maybe I'm missing something, but this sounds like an elegant solution? The > only downside is increased complexity in moc to find such instantiations. > Until clang can be used for moc, we could add a macro, lets say > Q_INSTANTIATE(Foo<int>), or similar. > > What do you say? What am I missing that would break my assumptions? > -- > 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_______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- 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
