On Tuesday 10 February 2015 23:10:01 André Pönitz wrote:
> > > Can't you simply wait until 'nullptr' is available? Do you really *need*
> > > to use macros instead of the core language?
> >
> > We go back to the discussion of VS2008. That's the only major compiler we
> > still care about that doesn't support it.
>
> You are inventing a problem that does not exist.
>
> '0' has served well enough as a null pointer constant in the past. There is
> no doubt it will do so for a few more years. VS2008 will be not an issue
> then.
>
> Getting the headers "clean" for the folks that "need" to turn on each and
> every possible compiler warning (and then can't stand the heat...) is one
> thing. Fine. Let them have Q_NULLPTR in the headers.
>
> But littering the implementation with it and keeping up the claim that
> replacing a core C++ idiom by *A MACRO* would be a step to _modernize_ is
> completely inapprehensible.
I understand that. I was not advocating in favour of using Q_NULLPTR or in
favour of preventing its use.
I merely reacted to your suggestion that we wait for the ability to use
nullptr itself. We can do that as soon as VS2008 is no longer a concern. Until
then, we can't discuss this.
My current thinking is:
1) modernise our headers with macros, now
2) allow people to use Q_NULLPTR where it helps with readability
3) disallow replacing of zeroes with Q_NULLPTR except as required by rules #1
or #2
Two examples:
a) void *ptr = 0;
b) str.toInt(0, 0);
In (a), use of Q_NULLPTR would make the code noisier, so don't use it. In (b),
the first 0 could be replaced with Q_NULLPTR to indicate that yes we know it's
a pointer, as opposed to an integer.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
