[Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

[Thiago Macieira]

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