To C++11 or not?

Martin Gräßlin mgraesslin at kde.org
Fri Dec 30 14:32:24 UTC 2016


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 <kfunk at 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?

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


More information about the Kde-frameworks-devel mailing list