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
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 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
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
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
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
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
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?
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
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
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.
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
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
I'll only comment on the application side:
On Thu, Aug 13, 2015 at 10:46 AM, Sergio Martins iamser...@gmail.com 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
On Thu, Aug 13, 2015 at 10:46 AM, Sergio Martins iamser...@gmail.com 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
On Thu, Aug 13, 2015 at 7:59 AM, Ivan Čukić ivan.cu...@kde.org 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
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
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
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
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
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
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
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
23 matches
Mail list logo
