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 j
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 su
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 plac
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 v
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?
S
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
> 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
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 bo
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
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.
> 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
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
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.
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
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 ti
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 th
> 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 in
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
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 KF
>> 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
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 nullpt
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
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 t
23 matches
Mail list logo