Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Friday 24 July 2015 20:23:45 Marc Mutz wrote: > Fair enough, but seeing all the commits flying by that add Q_D_O to "fix > warnings with clang", it's not hard to imagine that a) the problem will > solve itself by a grass roots movement and b) people will a > not-too-unrealistic future warning will complain not just about > inconsistent use, but any missing override, like the already-existing > warnings for nullptr. So if 5.6 is anything near 4.8, we'll probably add > those macros to a point release, by popular demand. I think it's worth it if there's a benefit in performance or in reduction of warnings. Doing it for the sake of doing it, not so much. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Friday 24 July 2015 20:23:45 Marc Mutz wrote: > itself by a grass roots movement and b) people will a not-too-unrealistic s/people will// -- Marc Mutz | Senior 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
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Friday 24 July 2015 17:43:59 Thiago Macieira wrote: > So the question is only whether we want to add the macro now and replace > with the keyword in 5.7. > > I'd say no. Fair enough, but seeing all the commits flying by that add Q_D_O to "fix warnings with clang", it's not hard to imagine that a) the problem will solve itself by a grass roots movement and b) people will a not-too-unrealistic future warning will complain not just about inconsistent use, but any missing override, like the already-existing warnings for nullptr. So if 5.6 is anything near 4.8, we'll probably add those macros to a point release, by popular demand. Thanks, Marc -- Marc Mutz | Senior 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
Re: [Development] Replace QtXml backend
On Friday 24 July 2015 15:26:30 Gerhard Scheikl wrote: > Hi > > Unfortunately, the QtXml classes contain a lot of bugs and are not really > maintained. Hello Gerhard Your question is answered mostly by your paragraph above: QtXml is in Done state, so we really don't want to do major surgery in it, which could open the door up for subtle incompatibilities. I'm not even talking about introducing bugs that aren't there. That's sure a concern. But even if you do your best, you may *fix* bugs that people are accidentally depending on; or the simple fact of a change in behaviour could result in existing code getting broken. Are you prepared to accept all of those reports and react to them? > So we came up with the idea to replace the back-end with Xerces and try to > leave the Qt API part the same. That's interesting. How big is Xerces? How easy is it to build? How is it licensed? > If we succeed, we would like to give this code back to the community and > replace the current QtXml classes. Do you include accepting maintainership of the module and reacting to bug reports in "give this code back to the community"? We're all for new and improved code, but when it comes with a large maintenance burden, we have to analyse whether it's worth the hassle. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Friday 24 July 2015 13:34:39 Marc Mutz wrote: > On Thursday 23 July 2015 16:29:12 Knoll Lars wrote: > > On 23/07/15 14:27, "Marc Mutz" wrote: > > >On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: > > >> * Q_DECL_OVERRIDE - required in new code, don't add to old code > > > > > >- Required to be used consistently within a class, because Clang warns be > > > > > > default if one function has override and another doesn't. > > > > > >- Even add to old code. The benefits outweigh the git history churn. > > > > > >Consensus? > > > > Yes, but again, I’d propose we wait until 5.6 is branched and then start > > using the keyword directly, not the macro. > > Is there any compiler we support that doesn't support it? Note: MSVC > supports it from 2005 (override; final was called 'sealed'). We don't claim to require C++11 in 5.6, so you cannot use the naked keyword, even if all of the compilers we support can understand it. It's possible someone is compiling Qt with some other compiler. So the question is only whether we want to add the macro now and replace with the keyword in 5.7. I'd say no. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Binary incompatible Qt 5 version
On Friday 24 July 2015 10:36:19 Peter Kuemmel wrote: > > Von: "Thiago Macieira" > > > > > > Mixing different Qt versions in the same process is not supported. I must > > point out that none of the backtraces in either link show this. > > You can't use plugins compiled with an older Qt version. > https://bugs.kde.org/show_bug.cgi?id=349371 Sure you can. Provided, of course, that the plugin isn't using private API. > I assume there are some toxic compiler flags which where maybe used by the > system Qt build. I don't see any evidence to support that assumption. > > >From what I can tell quickly examining both links, the root cause is not > > >yet> > > determined. > > At least this way: no crashes when old plugins are disabled. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Replace QtXml backend
On Fri, Jul 24, 2015 at 3:26 PM, Gerhard Scheikl wrote: > Hi > > Unfortunately, the QtXml classes contain a lot of bugs and are not really > maintained. > So we came up with the idea to replace the back-end with Xerces and try to > leave the Qt API part the same. > > Hi, pugixml has a benchmark with both Xerces and QtXml (and others) here: http://pugixml.org/benchmark.html It looks like Xerces is faster and it uses less memory than QtXml. Cheers, Cristian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Replace QtXml backend
Hi Unfortunately, the QtXml classes contain a lot of bugs and are not really maintained. So we came up with the idea to replace the back-end with Xerces and try to leave the Qt API part the same. Has anyone tried such an approach already? If we succeed, we would like to give this code back to the community and replace the current QtXml classes. Would this be possible? Would it be OK to introduce this new dependency? What do you think? Thanks Best regards Gerhard ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtbase 5.5 CI broken again ?
Rebooting windows is the first thing a windows user learns to do, why it takes so much to do it ? :) On Thursday, July 23, 2015 1:05 PM, Friedemann Kleint wrote: Hi, >As far as I know, no. No one has a clue why the creation of a temporary >directory is failing. It is simply running out of patterns to try since the mime DB tests leaked temp dirs. https://codereview.qt-project.org/#/c/121381/ fixed QDir::removeRecursively() to try harder removing files and https://codereview.qt-project.org/#/c/121383/ fixed the test to set write permission on the temp files it creates; the test should no longer leak. All that remains to be done is reboot the Windows CI nodes and clean out their temp directories. Friedemann -- Friedemann Kleint | The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contribute to the Qt
On Friday 24 July 2015 10:30:32 Peter Kuemmel wrote: > > Or do you want to help improve the C++11 support in Qt? > > Is there a TODO list about possible improvements? > And what's the policy about C++14? Isn't C++14 mostly > a patch/cleanup of C++11? List: we have the list from Thiago, which I asked yesterday on the list about re: consensus. That'd be - make sure public headers use Q_NULLPTR, not 0 (the devil is in the details here, just adding the warning to headerscheck doesn't find 0s in templates). - make sure Q_DECL_OVERRIDE is added everywhere (postponed to 5.7 for now) - make sure Q_DECL_NOTHROW / Q_DECL_NOEXCEPT / Q_DECL_NOEXCEPT_EXPR is added to relevant functions - make sure Q_DECL_(RELAXED_)CONSTEXPR is added whereever possible To which I'd add: - add qMove()s where it makes sense (e.g. QVector::append() these days). My personal agenda: - make sure value types aren't pessimised by careless disabling of the move special member functions (move assignment is generally easy, move ctors need the new smart pointer (https://codereview.qt-project.org/115213) and need to work with both QSharedDataPointer _and_ QExplicitlySharedDataPointer before they can be safely ported to QtPrivate::SharedDataPointer - that turns out to be surprisingly tricky in certain cases). - ditto, but in addition they're nothrow std::vector resizing performance heavily depends on a nothrow move constructor. But also QVector has gained _some_ move support (in append(), both lvale and rvalue overloads). C++14: There's not much different in terms of API design between C++11 and 14. Basically, currently we only have Q_DECL_RELAXED_CONSTEXPR vs. Q_DECL_CONSTEXPR. If we have polymorphic function objects, we probably should add is_transparent to them, but I don't think we have any. Well, QCollator maybe. Thanks, Marc -- Marc Mutz | Senior 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
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 24/07/15 13:34, "Marc Mutz" wrote: >On Thursday 23 July 2015 16:29:12 Knoll Lars wrote: >> On 23/07/15 14:27, "Marc Mutz" wrote: >> >On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: >> >> * Q_DECL_OVERRIDE - required in new code, don't add to old code >> > >> >- Required to be used consistently within a class, because Clang warns >>be >> > >> > default if one function has override and another doesn't. >> > >> >- Even add to old code. The benefits outweigh the git history churn. >> > >> >Consensus? >> >> Yes, but again, I’d propose we wait until 5.6 is branched and then start >> using the keyword directly, not the macro. > >Is there any compiler we support that doesn't support it? Note: MSVC >supports >it from 2005 (override; final was called 'sealed'). I believe they all support it, but in 5.6, we still allow compilation in C++98 mode, so it has to be a macro there. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On Thursday 23 July 2015 16:29:12 Knoll Lars wrote: > On 23/07/15 14:27, "Marc Mutz" wrote: > >On Thursday 08 January 2015 23:33:34 Thiago Macieira wrote: > >> * Q_DECL_OVERRIDE - required in new code, don't add to old code > > > >- Required to be used consistently within a class, because Clang warns be > > > > default if one function has override and another doesn't. > > > >- Even add to old code. The benefits outweigh the git history churn. > > > >Consensus? > > Yes, but again, I’d propose we wait until 5.6 is branched and then start > using the keyword directly, not the macro. Is there any compiler we support that doesn't support it? Note: MSVC supports it from 2005 (override; final was called 'sealed'). -- Marc Mutz | Senior 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
Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)
On 23/07/15 19:16, "Thiago Macieira" wrote: >On Thursday 23 July 2015 19:22:46 Marc Mutz wrote: >> I believe we should strive to have the LTS release warning-free in this >> regard. It's going to be in use for a long time, and the demand for >>nullptr- >> correctness will only grow with time. > >Agreed. > >I'd say go ahead with cleaning up zero-as-null in public headers and then >add >it to headersclean. > >For 5.7, we can do s/Q_NULLPTR/nullptr/g. Ok for me as well, if someone volunteers to do the job. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Binary incompatible Qt 5 version
> Von: "Thiago Macieira" > > > Mixing different Qt versions in the same process is not supported. I must > point > out that none of the backtraces in either link show this. You can't use plugins compiled with an older Qt version. https://bugs.kde.org/show_bug.cgi?id=349371 I assume there are some toxic compiler flags which where maybe used by the system Qt build. > > >From what I can tell quickly examining both links, the root cause is not yet > determined. At least this way: no crashes when old plugins are disabled. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contribute to the Qt
> > Or do you want to help improve the C++11 support in Qt? Is there a TODO list about possible improvements? And what's the policy about C++14? Isn't C++14 mostly a patch/cleanup of C++11? > > Or... > > Thanks, > Marc > > -- > Marc Mutz | Senior 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 > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
