Re: Using nullptr instead of Q_NULLPTR
I'll only comment on the application side: On Thu, Aug 13, 2015 at 10:46 AM, Sergio Martins wrote: > Btw, what are the c++98/c++11 requirements for applications ? I could only > find > the page for frameworks. For applications, it's 100% up to the application developer. I'm sure it wouldn't be nice if Kate now used C++14 features. However, if you are an application developer of an application that is kind of "optional", then it's you who decides, imho. Worst case is, that some distributions won't ship your app, but I'd consider that already unlikely, since distributions build their stuff with fairly recent compilers. Greetings, Dominik
Re: Using nullptr instead of Q_NULLPTR
On Thu, Aug 13, 2015 at 10:46 AM, Sergio Martins wrote: > Hi, > > > https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11 > states gcc 4.5 as the minimum version, meaning we can't use nullptr. > > However, since some time now, kf5 libraries are full of nullptr (~400 > occurrences) and nobody noticed. > > We can either: > - Bump the requirement to gcc 4.6 and allow nullptr > - Fix kf5 and s/nullptr/Q_NULLPTR > > > I prefer the first option, it's the way forward and if someone was using an > old > gcc he would have complained by now. > > > Btw, what are the c++98/c++11 requirements for applications ? I could only > find > the page for frameworks. > > > Regards, > -- > Sérgio Martins > I'd say that requiring a newer gcc just like that would go against the nature of the KF5 project. Let's fix it for now, even increase the testing to make sure that what we promise is going to work, will, and then we can decide to bump the gcc dependencies together with Qt, eventually. Aleix
Re: Using nullptr instead of Q_NULLPTR
>> I prefer the first option, it's the way forward and if someone was using > > I'd say that requiring a newer gcc just like that would go against the > nature of the KF5 project. I don't really see why it is "against the nature of KF5". It would not be the first time we require a higher compiler version than the one required by the Qt version we require. Qt 5.5 requires gcc 4.8 for linux and windows. So even they increment the versions from time to time. We can switch everything to Q_NULLPTR even without anyone complaining about it, but we will have to switch back in a few releases. Cheerio, Ivan
Re: Using nullptr instead of Q_NULLPTR
On Thu, Aug 13, 2015 at 7:59 AM, Ivan Čukić wrote: > >> I prefer the first option, it's the way forward and if someone was using > > > > I'd say that requiring a newer gcc just like that would go against the > > nature of the KF5 project. > > I don't really see why it is "against the nature of KF5". It would not > be the first time we require a higher compiler version than the one > required by the Qt version we require. > > Qt 5.5 requires gcc 4.8 for linux and windows. So even they increment > the versions from time to time. > > We can switch everything to Q_NULLPTR even without anyone complaining > about it, but we will have to switch back in a few releases. > > Cheerio, > Ivan > Qt 5.1 is still officially supported [1] and its minimum requirement is gcc 4.6.1 on Linux platform, 4.4.1 on Arm and 4.2 on OS X (?!). Qt 5.5 can be compiled with gcc 4.6.3 according to [1], so bumping the requirement to 4.6.1 seems reasonable. [1] http://doc.qt.io/QtSupportedPlatforms/ Lamarque V. Souza http://planetkde.org/pt-br
Re: Using nullptr instead of Q_NULLPTR
On Thursday 13 of August 2015 12:59:01 Ivan Čukić wrote: > >> I prefer the first option, it's the way forward and if someone was using > > > > I'd say that requiring a newer gcc just like that would go against the > > nature of the KF5 project. > > I don't really see why it is "against the nature of KF5". It would not > be the first time we require a higher compiler version than the one > required by the Qt version we require. But then we need a clear agreement. I don't care about proprietary compilers whose version released two years ago does not support extensions supported for years already by FLOSS compilers. What I don't like in this story is that we set up a rule, an promise with users, which was broken and now it's like it does not matter. > > Qt 5.5 requires gcc 4.8 for linux and windows. So even they increment > the versions from time to time. > > We can switch everything to Q_NULLPTR even without anyone complaining > about it, but we will have to switch back in a few releases. But we are not there in those few releases, which could be months away. The things to do is follow the rule and revert the changes, and then *after* change the rule. IMHO. Ciao -- Luigi
Re: Using nullptr instead of Q_NULLPTR
> What I don't like in this story is that we set up a rule, an promise with > users, which was broken and now it's like it does not matter. Yes, we did set up the rule requirements for gcc 4.5 and MSVC10 back in 2013. Since then, we broke the rule and increased to MSVC11 (VS2012). Now, we can increase, if we want to, the gcc requirement to 4.6. If you think that the additional work of writing a patch, then increasing the compiler version requirement, and then reverting the patch is warranted, it is fine by me. As Lamarque pointed out, gcc 4.6 is required for Qt 5.1. KF5 requires Qt 5.3. If someone is able to compile Qt, he will be able to compile KF5 - I guess that is the reason this issue has passed unnoticed for this long. Cheerio, Ivan
Re: Using nullptr instead of Q_NULLPTR
On Thursday 13 of August 2015 15:01:16 Ivan Čukić wrote: > > What I don't like in this story is that we set up a rule, an promise with > > users, which was broken and now it's like it does not matter. > > Yes, we did set up the rule requirements for gcc 4.5 and MSVC10 back in > 2013. > > Since then, we broke the rule and increased to MSVC11 (VS2012). > > Now, we can increase, if we want to, the gcc requirement to 4.6. > > If you think that the additional work of writing a patch, then > increasing the compiler version requirement, and then reverting the > patch is warranted, it is fine by me. > > As Lamarque pointed out, gcc 4.6 is required for Qt 5.1. KF5 requires > Qt 5.3. If someone is able to compile Qt, he will be able to compile > KF5 - I guess that is the reason this issue has passed unnoticed for > this long. I apologize, I mixed up two different emails that came today on a similar topic. There is nothing to discuss on this, given the requirement of Qt 5.1. Please take a look also at "Minimum supported version of MSVC for frameworks" on kde-frameworks-devel. Ciao -- Luigi
Re: Using nullptr instead of Q_NULLPTR
On Thursday 13 August 2015 12:59:01 Ivan Čukić wrote: > Qt 5.5 requires gcc 4.8 for linux and windows. So even they increment > the versions from time to time. s/8/5/ and you'd be correct. The Qt minimum version will rise to GCC 4.7 with Qt 5.7 and Qt will stop compiling in C++98 mode at that time. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Using nullptr instead of Q_NULLPTR
This is from the "Officially supported platforms" page at http://doc.qt.io/QtSupportedPlatforms/ Qt 5.5: Windows * - MinGW 4.9, MinGW 4.8 (apart from MSVC) Linux - 32/64bitgcc 4.8.1, gcc 4.9.1 I thought that was official enough. Cheers, Ivan
Re: Using nullptr instead of Q_NULLPTR
On Friday 14 August 2015 01:08:19 Ivan Čukić wrote: > This is from the "Officially supported platforms" page at > http://doc.qt.io/QtSupportedPlatforms/ > > Qt 5.5: > Windows * - MinGW 4.9, MinGW 4.8 (apart from MSVC) > Linux - 32/64bitgcc 4.8.1, gcc 4.9.1 > > I thought that was official enough. It isn't. The page is just plainly wrong. That's the list of platforms the Qt CI tests on. It's not the list of platforms we are supposed to compile with and support. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Using nullptr instead of Q_NULLPTR
We could just detect the compiler, and in need define nullptr 0x0, look the other side and hope for the best (ie. anybody on modern compilers anyway and nobody actually making use of std::nullptr_t atm. but just of the keyword) - not very nice, but better than breaking compilation(?) and not as invasive. Cheers, Thomas
Re: Using nullptr instead of Q_NULLPTR
> It isn't. The page is just plainly wrong. In that case, I retract my previous comments. Where are the *proper* requirements documented then (for future reference)? > That's the list of platforms the Qt CI tests on. It lists both CI tested and untested things there. -- Cheerio, Ivan
Re: Using nullptr instead of Q_NULLPTR
Sergio Martins wrote: > https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11 > states gcc 4.5 as the minimum version, meaning we can't use nullptr. > > However, since some time now, kf5 libraries are full of nullptr (~400 > occurrences) and nobody noticed. > > We can either: > - Bump the requirement to gcc 4.6 and allow nullptr > - Fix kf5 and s/nullptr/Q_NULLPTR > > Hi, I found the the inconsistency in frameworks while thinking about adding some null pointer policy for some k*.git repos I maintain. > I prefer the first option, it's the way forward and if someone was using > an old gcc he would have complained by now. This is a good point. This thread drifted in a direction of minimum compiler versions supported. If I read the changelogs correctly msvc is like 8 years ahead of gcc (4.6) in this department. MSVC 2005 supported it already, this is enough for us I think. Now in 2015 I propose to go with nullptr. Not using Q_NULLPTR removes on point against accepting Qt observed among 3rd-party folks: "Qt guys, like the EFL guys, like to invent everything from scratch". A tiny bit but always. I also think we agree that anything other than 0 is good for readability and readability should be the priority. Then, there's the consistency factor -- a reason to cover the topic of null pointers in the guide. I find neither Qt is consistent in what to use, Qt is not an example here then. A patch for changing Q_NULLPTRs and NULLs is trivial to make but it's better to have it once and not doing further undos, otherwise the git-blame will be unnecessarily polluted. A patch for 0's would be a JJ. In the worst case if someone calls us too modern, e.g for embedded projects, we'd be able a macro to ECM kdecompilersettings that defined nullptr back to 0 (or is this already supported by cmake/etc.?) Thoughts? PS: A Krazy check checking for usage of NULLs and Q_NULLPTR would be lovely. Checking the use of 0's isn't easy, right? Maybe I'll use pre-commit hook personally. > > Btw, what are the c++98/c++11 requirements for applications ? I could only > find the page for frameworks. > > > Regards, > -- > Sérgio Martins -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Using nullptr instead of Q_NULLPTR
On Friday, August 14, 2015 02:34:49 PM Jarosław Staniek wrote: > > PS: A Krazy check checking for usage of NULLs and Q_NULLPTR would be lovely. > Checking the use of 0's isn't easy, right? > Already done, since 2007. but it's in the "extra" checkers, ie. not enabled by default. Currently the checker suggests using 0 (or Q_NULLPTR for Qt5/KF5 code) instead of NULL. I can make it a default checker if desired and/or change the behavior. Tell me what you want and I'll implement. To test the current implementation, create a .krazy file at the top of your project with the line "EXTRA null"
Re: Using nullptr instead of Q_NULLPTR
On Friday 14 August 2015 08:28:51 Ivan Čukić wrote: > > It isn't. The page is just plainly wrong. > > In that case, I retract my previous comments. Where are the *proper* > requirements documented then (for future reference)? > > > That's the list of platforms the Qt CI tests on. > > It lists both CI tested and untested things there. I would have said the docs or the wiki somewhere, but I've just discovered that the docs are wrong... :-) -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Using nullptr instead of Q_NULLPTR
> I would have said the docs or the wiki somewhere, but I've just discovered > that the docs are wrong... :-) Heh, I had the same approach. :) -- Cheerio, Ivan
Re: Using nullptr instead of Q_NULLPTR
On Friday 14 August 2015 14:34:49 Jarosław Staniek wrote: > I also think we agree that anything other than 0 is good for readability > and readability should be the priority. Note that the Qt 5.7 policy still allows and even asks for use of 0 as null in some places. The policy is: * always use nullptr in public headers. No exceptions. * use nullptr or 0 in non-public headers or regular sources so readability is good. There's no point in using nullptr where 0 is obviously a null pointer, like: char *s = 0; > Then, there's the consistency factor -- a reason to cover the topic of null > pointers in the guide. I find neither Qt is consistent in what to use, Qt > is not an example here then. The policy above applies to Qt 5.7. For 5.6, only the first part applies and it needs to be Q_NULLPTR. > In the worst case if someone calls us too modern, e.g for embedded > projects, we'd be able a macro to ECM kdecompilersettings that defined > nullptr back to 0 (or is this already supported by cmake/etc.?) Don't do that. If you use nullptr, there's no going back to zero because it's not the same. You've irrevocably locked yourself into requiring a compiler that supports it. > PS: A Krazy check checking for usage of NULLs and Q_NULLPTR would be > lovely. Checking the use of 0's isn't easy, right? -Wzero-as-null-pointer-constant Qt headers should pass that starting with 5.6. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Using nullptr instead of Q_NULLPTR
On Freitag, 14. August 2015 22:34:28 CEST, Thiago Macieira wrote: Don't do that. If you use nullptr, there's no going back to zero because it's not the same. You've irrevocably locked yourself into requiring a compiler that supports it. Even if it's only been used in a 0x0 "compliant" way? Some ABI trap? In that case there's not much to discuss, is there? KF5 "now" requires a compiler that support nullptr. Regards, Thomas
Re: Using nullptr instead of Q_NULLPTR
On Friday 14 August 2015 04:07:41 Thomas Lübking wrote: > We could just detect the compiler, and in need define nullptr 0x0, look the > other side and hope for the best (ie. anybody on modern compilers anyway > and nobody actually making use of std::nullptr_t atm. but just of the > keyword) - not very nice, but better than breaking compilation(?) and not > as invasive. It's not the same thing. First of all, it can't be a variable, it would have to be a macro. Second, a literal zero can be cast to boolean, integrals and floating point, but nullptr can't. That's the whole reason why nullptr exists in the first place. Q_NULLPTR isn't nullptr: when you use it, you acknowledge that it may be a zero and thus won't resolve ambiguities when calling overloads -- or, worse, will call the wrong overload (the one with int instead of the one with a pointer). Defining a macro for nullptr is dangerous... My recommendation: it's broken now so leave it. Fix it if someone complains, but otherwise just leave it. In one year's time, the discussion will be moot. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Using nullptr instead of Q_NULLPTR
Thiago Macieira wrote: > On Friday 14 August 2015 14:34:49 Jarosław Staniek wrote: >> I also think we agree that anything other than 0 is good for readability >> and readability should be the priority. > > Note that the Qt 5.7 policy still allows and even asks for use of 0 as > null in some places. The policy is: > > * always use nullptr in public headers. No exceptions. > * use nullptr or 0 in non-public headers or regular sources so > readability is >good. There's no point in using nullptr where 0 is obviously a null >pointer, like: > char *s = 0; > >> Then, there's the consistency factor -- a reason to cover the topic of >> null pointers in the guide. I find neither Qt is consistent in what to >> use, Qt is not an example here then. > > The policy above applies to Qt 5.7. For 5.6, only the first part applies > and it needs to be Q_NULLPTR. > >> In the worst case if someone calls us too modern, e.g for embedded >> projects, we'd be able a macro to ECM kdecompilersettings that defined >> nullptr back to 0 (or is this already supported by cmake/etc.?) > > Don't do that. If you use nullptr, there's no going back to zero because > it's not the same. You've irrevocably locked yourself into requiring a > compiler that supports it. I should say "back to Q_NULLPTR", right? It's just helping people with old compilers by making the code SC. >> PS: A Krazy check checking for usage of NULLs and Q_NULLPTR would be >> lovely. Checking the use of 0's isn't easy, right? > > -Wzero-as-null-pointer-constant > > Qt headers should pass that starting with 5.6. Yes it's useful for KF5. @everyone: can we have have it added in our build flags for KF5 (maybe not for users of KF5)? -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Using nullptr instead of Q_NULLPTR
On Fri, August 14, 2015 22:49:44 Thomas Lübking wrote: > On Freitag, 14. August 2015 22:34:28 CEST, Thiago Macieira wrote: > > Don't do that. If you use nullptr, there's no going back to > > zero because it's > > not the same. You've irrevocably locked yourself into requiring a compiler > > that supports it. > > Even if it's only been used in a 0x0 "compliant" way? > Some ABI trap? A source compat trap perhaps. nullptr is unequivocally a *pointer*, and names the null pointer for whatever pointer type it's cast to. 0 can be a pointer or an integer, so code that previously 'worked' using nullptr might become ambiguous (or worse, change behavior) if switched to 0. In fact there was a JuK bug with gstreamer many years ago where 64-bit JuK would crash because passing NULL as a sentinel to a gstreamer varargs function was turned into passing 0, which C++ treated as an (32-bit) int instead of a pointer due to its use as a varargs argument. This wouldn't have happened if nullptr had been used. Regards, - Michael Pyne
Re: Using nullptr instead of Q_NULLPTR
On Friday 14 August 2015 23:53:44 Jarosław Staniek wrote: > > Don't do that. If you use nullptr, there's no going back to zero because > > it's not the same. You've irrevocably locked yourself into requiring a > > compiler that supports it. > > I should say "back to Q_NULLPTR", right? > > It's just helping people with old compilers by making the code SC. Back to anything that is not nullptr: 0, NULL, __null, Q_NULLPTR, whatever. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
