On Friday 18 December 2015 14:04:03 René J. V. Bertin wrote:
> I saw mention of a Q_xxx macro in this thread (and lots of code using it).
> If it has been argued here already, let me add my voice to the opinion that
> this implies a Qt-specific type that should only be used in calls to Qt
> functio
The invention of the 0 concept was a revolution; are we facing something
similar
here? :)
Milian Wolff wrote:
> This, for me, is btw. a very strong argument in favor of requesting nullptr
> everywhere.
Or of using 0 everywhere, but not having read the entire thread I must presume
good reason
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 val
> 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 -Werror=zero-as-nullptr outside of
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 m_foo(null
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 there
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
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 backtrace/de
02 PM
To: development@qt-project.org
Subject: 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
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.
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.
>
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 insignificant
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,
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
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
___
On Wednesday 09 December 2015 17:41:26 Matthew Woehlke wrote:
> On 2015-12-09 17:29, Thiago Macieira wrote:
> > On Wednesday 09 December 2015 22:47:51 Marc Mutz wrote:
> >
> > I'd like to propose this:
> > [...]
> > c) which means no -Werror=zero-as-nullptr outside of headersclean
>
> I just wa
On 2015-12-09 17:29, Thiago Macieira wrote:
> On Wednesday 09 December 2015 22:47:51 Marc Mutz wrote:
> I'd like to propose this:
> [...]
> c) which means no -Werror=zero-as-nullptr outside of headersclean
I just want to say that I think this is fair. The key phrase there is
"outside of". -Wzero
On Wednesday 09 December 2015 22:54:22 Marc Mutz wrote:
> Whatever happened to KISS?
That's a good reason not to run clang-modernize and force people to review.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
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 5.7, we would be able to use the real thing and didn't want the
> double convers
On Wednesday 09 December 2015 16:14:00 Marc Mutz wrote:
> Hi,
>
> in 5.7, nullptr (Q_C_NULLPTR) is required to be supported by the compiler,
> but there are no guidelines as to its use in the coding conventions (to
> the extent they need to be in there).
>
> I propose the following, based on Thia
On Wednesday 09 December 2015 19:11:29 Thiago Macieira wrote:
> On Wednesday 09 December 2015 16:14:00 Marc Mutz wrote:
> > - 0 as a nullptr constant is banned except in tests testing APIs so
> >
> > we don't accidentally require nullptr (ie. all tests should use 0, not
> > nullptr, as far as i
On Wednesday 09 December 2015 16:14:00 Marc Mutz wrote:
> - 0 as a nullptr constant is banned except in tests testing APIs so
> we don't accidentally require nullptr (ie. all tests should use 0, not
> nullptr, as far as it makes sense)
This is not what we had agreed to.
We had said that where
On Wednesday 09 December 2015 16:38:02 Joerg Bornemann wrote:
> > - if (!foo) vs. if (foo == nullptr), if (foo) vs. if (foo != nullptr):
> >author's prerogative[1]
[...]
> > [1] I prefer the short form, but I don't think we'll gain a consensus
> > here, so let's not even try
>
> So why do you
On Wednesday 09 December 2015 16:19:38 Matthew Woehlke wrote:
> > - APIs that require the use of nullptr for disambiguation are
> > discouraged,
> >
> > but may be acceptable to be decided on a case-by-case basis.
>
> On that note, there is one case in which '0' as nullptr makes sense...
> defau
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 two sets of rules for headers and impl
- it can disamb
On 09-Dec-15 16:14, Marc Mutz wrote:
in 5.7, nullptr (Q_C_NULLPTR) is required to be supported by the compiler, but
there are no guidelines as to its use in the coding conventions (to the extent
they need to be in there).
There are also no guidelines for every other language feature, and I
do
On 2015-12-09 10:14, Marc Mutz wrote:
> in 5.7, nullptr (Q_C_NULLPTR) is required to be supported by the compiler,
> but
> there are no guidelines as to its use in the coding conventions (to the
> extent
> they need to be in there).
>
> I propose the following, based on Thiago's proposal from
On Wednesday, 9 December 2015 16:14:00 WET Marc Mutz wrote:
> 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 two sets of rules for headers and i
Hi,
in 5.7, nullptr (Q_C_NULLPTR) is required to be supported by the compiler, but
there are no guidelines as to its use in the coding conventions (to the extent
they need to be in there).
I propose the following, based on Thiago's proposal from January this year,
considering the new situation
29 matches
Mail list logo
