On Monday, 14 November 2016 10:45:07 CET Martin Gräßlin wrote: > Hi framework devs, > > recently we started to see the first patches for frameworks to silence > warnings for not used features of C++11. In particular to add override > to methods of inheriting classes. > > Now I find this weird from the perspective of our C++ requirements. On > the one side we say that we are not allowed to use these features to > still support non-C++11 compilers on the other side we see that > compilers already generate warnings if you don't use the C++11 features. > > In that particular case I do not think that Q_DECL_OVERRIDE is a > solution. It's an ugly hack and for the frameworks I maintain I gave a > -2 on the review. I think this needs a general solution of either not > adding or adding override, but not the Qt hack. > > I think this is a sign that we need to move on. We cannot continue with > the state we are in. It's too much a hassle for developers: > * false-positive compile warnings > * no way to check which features are allowed or not > * no warnings if a not allowed feature is used > * no CI system in place to ensure our rules > > Given that I want to suggest that we remove all compiler restrictions > and allow the full feature set of C++11. If someone still thinks we need > to support the compilers not supporting C++11, I would like to see a > plan on how we can improve the developer story, especially how to > address the last two points in my list above. > > Opinions?
Heya, 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. Cheers, Kevin [1] https://community.kde.org/Frameworks/ Policies#Frameworks_compiler_requirements_and_C.2B.2B11 [2] http://en.cppreference.com/w/cpp/compiler_support [3] https://gcc.gnu.org/releases.html [4] https://en.wikipedia.org/wiki/Microsoft_Visual_Studio#History > Cheers > Martin -- Kevin Funk | kf...@kde.org | http://kfunk.org
signature.asc
Description: This is a digitally signed message part.