Re: [Development] RFF: nullptr rules

Am 09.12.2015 um 17:45 schrieb Mathias Hasselmann: Am 09.12.2015 um 16:14 schrieb Marc Mutz: Arguments in favour: - it's the C++ way of writing the null pointer constant these days - we need to use it in headers, anyway, to allow people to use -Wzero-as..., and it makes no sense to have

Re: [Development] RFF: nullptr rules

On 09-Dec-15 19:41, Marc Mutz wrote: What part of "author's prerogative" was unclear? Unclear is, why you take the time to answer but horribly fail to explain why you deem it necessary to enforce this particular insignificant language glitch fix. Thanks, Joerg

Re: [Development] RFF: nullptr rules

On Thursday 10. December 2015 10:52:15 Mathias Hasselmann wrote: > Am 09.12.2015 um 17:45 schrieb Mathias Hasselmann: > > Am 09.12.2015 um 16:14 schrieb Marc Mutz: > >> Arguments in favour: > >> - it's the C++ way of writing the null pointer constant these days > >> - we need to use it in headers,

Re: [Development] RFF: nullptr rules

On Thursday 10 December 2015 10:25:14 Joerg Bornemann wrote: > On 09-Dec-15 19:41, Marc Mutz wrote: > > What part of "author's prerogative" was unclear? > > Unclear is, why you take the time to answer but horribly fail to explain > why you deem it necessary to enforce this particular

[Development] Qt 5.6.0 Beta candidate packages available

Hi, We have finally Qt 5.6.0 beta candidate packages available: Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/224/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/290/ Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/283/ src:

Re: [Development] RFF: nullptr rules

On Thursday 10 December 2015 16:24:02 Sergio Martins wrote: > > But I don't think we should mandate use of nullptr everywhere. Where it's > > unambiguous, it doesn't add value. > > bool foo = 0; > > This is unambiguous, just like your "const char *ptr = 0" example, so "= > false" wouldn't add

Re: [Development] RFF: nullptr rules

On 10-Dec-15 17:23, Sergio Martins wrote: - in some situations, it makes code easier to understand (: m_foo(nullptr)). So nullptr is easier to understand, because assigning 0 to a pointer variable didn't make clear that it now contains a null pointer? If there's need to signify using

Re: [Development] RFF: nullptr rules

> On 09 Dec 2015, at 23:29, Thiago Macieira wrote: > > I'd like to propose this: > a) no massive replacement or clang-modernize, for the reasons Richard pointed > out > b) which means existing zeroes continue in sources and private headers > c) which means no

Re: [Development] RFF: nullptr rules

On Donnerstag, 10. Dezember 2015 14:36:49 CET Marc Mutz wrote: > As for why we need to have rules for nullptr: It's a funny you should ask, > because you're contributing to a project that mandates the placement of {}s > in minute detail. It's unclear why there should be no guideline for 0 vs. >

Re: [Development] RFF: nullptr rules

On 10-Dec-15 14:36, Marc Mutz wrote: As for why we need to have rules for nullptr: It's a funny you should ask, because you're contributing to a project that mandates the placement of {}s in minute detail. It's unclear why there should be no guideline for 0 vs. nullptr if there is for for() vs.

Re: [Development] Qt 5.6.0 Beta candidate packages available

Hi! Mirroring in ongoing. Splitted src packages will be in download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/submodules Br, Jani From: heliocas...@gmail.com [mailto:heliocas...@gmail.com] On Behalf Of Helio Chissini de Castro Sent: 10. joulukuuta 2015 13:57 To: Heikkinen Jani

Re: [Development] Qt 5.6.0 Beta candidate packages available

Hello Thanks for that. Best, Helio On Thu, Dec 10, 2015 at 2:10 PM, Heikkinen Jani < jani.heikki...@theqtcompany.com> wrote: > Hi! > > > > Mirroring in ongoing. Splitted src packages will be in > download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/submodules > > > > Br, > > Jani > > > >

Re: [Development] buildsystem now needs to keep behaviour compatibility

On 10/12/15 15:37, "Development on behalf of Koehne Kai" wrote: > > >> -Original Message- >> From: Development [mailto:development-boun...@qt-project.org] On >> Behalf Of Oswald Buddenhagen >> Sent:

Re: [Development] RFF: nullptr rules

On 10-Dec-15 15:25, Bubke Marco wrote: I think it less a technical issue. To me it looked very perlish to use zero to mark a defined invalid pointer but C++ is full of this expert language hacks. You still will need this thourough expert knowledge if you encounter a crash and the

Re: [Development] RFF: nullptr rules

I think it less a technical issue. To me it looked very perlish to use zero to mark a defined invalid pointer but C++ is full of this expert language hacks. I think it is more a social issue because Qt can look to old fashion. New people who discover Qt maybe get the same feeling as I got in

Re: [Development] buildsystem now needs to keep behaviour compatibility

> -Original Message- > From: Development [mailto:development-boun...@qt-project.org] On > Behalf Of Oswald Buddenhagen > Sent: Wednesday, December 09, 2015 11:45 AM > To: development@qt-project.org > Cc: releas...@qt-project.org > Subject: Re: [Development] buildsystem now needs to keep

Re: [Development] RFF: nullptr rules

On Wednesday, 9 December 2015 14:29:19 WET Thiago Macieira wrote: > On Wednesday 09 December 2015 22:47:51 Marc Mutz wrote: > > > const char *ptr = 0; > > > > What we agreed on was for Q_NULLPTR. > > > > Some developers back then were complaining that the *macro* is ugly, and > > that by

Re: [Development] RFF: nullptr rules

On Wednesday, 9 December 2015 16:38:02 WET Joerg Bornemann wrote: > > - in some situations, it makes code easier to understand (: > > m_foo(nullptr)). > So nullptr is easier to understand, because assigning 0 to a pointer > variable didn't make clear that it now contains a null pointer? > If