El divendres, 30 de desembre de 2016, a les 15:32:24 CET, Martin Gräßlin va escriure: > Am 2016-12-30 15:25, schrieb David Faure: > > On vendredi 30 décembre 2016 12:56:09 CET Albert Astals Cid wrote: > >> El divendres, 30 de desembre de 2016, a les 12:24:38 CET, Luigi > >> Toscano va > >> > >> escriure: > >> > Il 30 dicembre 2016 10:30:22 CET, Kevin Funk <kf...@kde.org> ha scritto: > >> > >Following-up on this thread, since I saw some more discussion about > >> > >C++11 > >> > > > >> > >usage in this RR: > >> > > https://git.reviewboard.kde.org/r/129724/ > >> > > > >> > >Let's put this into some concrete actions, finally. I think we all > >> > >agree > >> > >nullptr & override are probably the most apparent issues (since > >> > >compilers > >> > >started to warn about both), and *having* 'override' is actually super > >> > >useful > >> > >for preventing programmer faults. > >> > > > >> > >Let's just speak about allowing nullptr & override, allowing the full > >> > >set of C > >> > >++11 is *not* feasible. Reason: Lot's of C++11 feature are only > >> > >available only > >> > >in MSVC2015, so we'd just be able to support the latest VS. See [2]. > >> > > > >> > >Looking at [1] I still see we list GCC 4.5 as minimum requirement. > >> > >That's > >> > >pretty ancient. 4.5.1 got released Jul 2010 [3] > >> > > > >> > >If we raise that to GCC 4.6 (4.6.0 being released Mar 2011), we can > >> > >use > >> > > > >> > >'nullptr' unconditionally. ktexteditor already did that in public > >> > >headers for > >> > >quite some time -- no-one complained. > >> > > > >> > >If we raise that to GCC 4.7 (4.7.0 being released Mar 2012), we can > >> > >use > >> > > > >> > >'override' unconditionally *. > >> > > > >> > >We already use MSVC2012 as min VS dep, this version has full nullptr & > >> > >override support. I don't see anyone using MSVC2010 for compiling KF5 > >> > >to be > >> > >honest... > >> > > > >> > >Proposal for [1]: > >> > >- Raise min GCC version to 4.7 > >> > >- Allow to use override unconditionally > >> > >- Allow to use nullptr unconditonally > >> > > > >> > >ACK? > >> > > > >> > > > >> > >PS: I can do the work, I can script the refactoring with clang-tidy. > >> > > > >> > >Let's move forward please. > >> > > >> > Hi, this is a really good analysis (also for future reference). In > >> > order > >> > to > >> > complete it, given that the original idea was "follow Qt's > >> > requirement", > >> > and that we increased in time the required version of Qt, what is the > >> > current status regarding compilers and Qt? > >> > >> Our min requirement is Qt 5.5 which according to > >> http://doc.qt.io/qt-5/supported-platforms-and-configurations.html > >> compiles with GCC 4.6 (Qt 5.6 has the same supported GCC it seems) > > > > Then that's a no-brainer, we can require gcc 4.6 too. > > > > Qt 5.9 (currently "git dev branch") uses override rather than > > Q_DECL_OVERRIDE, > > but we're far from requiring 5.9. > > > > This leads to a different proposal: > > - Raise min GCC version to 4.6 > > - Allow to use nullptr unconditionally > > - Use Q_DECL_OVERRIDE. > > > > I fully agree that "having 'override' is actually super useful for > > preventing > > programmer faults", but that also works if it's spelled out > > Q_DECL_OVERRIDE > > and only ineffective for people *using* frameworks on an older system > > with gcc > > 4.6. It's still effective for all of us who are working on frameworks, > > which > > is where the benefit of "override" is. > > What's the plan to enforce that? How is build.kde.org checking that we > don't use override instead of Q_DECL_OVERRIDE?
I guess you can stop worrying. Stephen Kelly just reverted that change that had been approved in a review request without any discussion. Very sad, Albert > > This is the point I disagree with. We define nice rules and have no > means at all to ensure that they are enforced. That's something I have > brought to the attention of this mailing list several times over the > last years. Unfortunately nothing has changed. > > In my opinion we are lying to ourself and to everybody who wants to use > frameworks if we say "can be compiled with gcc 4.6" when we aren't even > testing that. > > So please let's get the ordering right: ensure that it compiles with gcc > 4.6, then say we support that. The only other option is to say we > require whatever gcc version build.kde.org is using. > > Cheers > Martin
