To C++11 or not?

[Kevin Funk]

On Friday, 30 December 2016 15:25:56 CET David Faure wrote:
> 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.

+1 from my side. I didn't know that we wanted to follow the Qt version's 
minimum compiler requirements. Makes sense.

Thanks for chiming in!

I'll port KF5 (at least the (public) headers) to nullptr if this proposal is 
accepted.

Cheers,
Kevin

> 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.
> 
> BTW just to get a taste of the real world, I'm working with a customer right
> now who is using Qt 5 and gcc 4.4 in order for their binaries to work on
> the largest possible number of Linux distros out there (glibc version).
> They are not using KDE Frameworks, obviously, but this is just to point out
> that there are companies using older gcc versions still, this is not just
> hypothetical.
> 
> Funny that I kept saying "MSVC is what's holding us back" when in fact it's
> GCC that is holding us back ;)
> 
> 
> PS: I disagree with the "nobody complained" approach. Many people will
> simply choose another library than complain about one library not being
> suited to their constraints (one of which being the supported compiler).


-- 
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/d4855322/attachment.sig>