To C++11 or not?

Fri Dec 30 15:02:17 UTC 2016

On Friday, 30 December 2016 15:32:24 CET Martin Gräßlin wrote:
> 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?

One instance that enforces this: code reviews.

> 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.

Well, there's only so much effort you can spend on Continuous Integration 
systems. You can't possibly test all system configurations out there.

> 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.

KF5 also claims that it can be compiled with MSVC2012+ and Clang 3.1+ and we 
have no means to prove it via the CI system either. It's not in place.

We still make sure it may possibly work on them by defining a set of rules (in 
the wiki), which are hopefully enforced when someone reviews code. Irregular 
testing happens when e.g. /me compiles KF5 using Clang or VS2015.

There's only so much you can do.

> 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.

I agree it would be perfect to have GCC 4.6 for KF5 in place (or some other 
mechanism to make sure 'override' is not used). But not having it doesn't mean 
we can't claim we're supporting, or at least trying to support GCC 4.6.

Two different things.

Cheers,
Kevin

> Cheers
> Martin

-- 
Kevin Funk | kfunk at kde.org | http://kfunk.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20161230/63a64ec1/attachment.sig>