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

[André Pönitz]

On Mon, Feb 09, 2015 at 12:07:15AM +0100, Allan Sandfeld Jensen wrote:
> On Sunday 08 February 2015, André Pönitz wrote:
> > On Sun, Feb 08, 2015 at 10:17:40PM +0100, Allan Sandfeld Jensen wrote:
> > > What would be the point of macros if they always expanded? The entire
> > > point and usefulness of these macros is that they expand to standard
> > > keywords when those standard keywords exists.
> > 
> > What's the point of using a macro in circumstances where a portable,
> > standard conforming, safe-to-use, shorter-to-type, version _without_ using
> > a macro exists?
> > 
> > I.e. in case of a simple pointer initialization, why should one *ever*
> > prefer
> > 
> > void something() { Foo *f = Q_NULLPTR; ...  }
> > 
> > over
> > 
> > void something() { Foo *f = 0; ...  }
> > 
> > ?
> > 
> > For the sake of keeping this part of the discussion simple, I specifically
> > mean 'Q_NULLPTR, the macro', _not_ 'nullptr', and I specifically mean the
> > context of initializing a local pointer variable. So: Any advantage? Any
> > advantage outweighing the disadvantages?
> > 
> If you use in the wrongly in a function call where integers are supposed to
> be used, we will get an error on the C++11 enabled builds even it if passes
> on C++98. Could also expose wrong implied constructors being used.
> 
> I am not a big fan of nullptr, but it makes sense in a few places, and can
> see the point in use Q_NULLPTR there.

I already mentioned earlier in this thread ("last year") that I agree that
nullptr makes sense in a few, selected places, and I might agree that until
nullptr can be used, using Q_NULLPTR in those selected places _might_ make
sense.

I am fairly sure that we won't reach consensus on what the set of such selected
places exactly look like, that's why the plan to reach _some_ conclusion was to
restrict a part of the discussion to one case where I think there's a chance to
get consensus that the use of the Q_NULLPTR macro is "obvious" nonsense.

I wrote:

 For the sake of keeping this part of the discussion simple, I specifically
 mean 'Q_NULLPTR, the macro', _not_ 'nullptr', and I specifically mean the
 context of initializing a local pointer variable. So: Any advantage? Any

Again, the case under consideration is 

 "{ Foo *f = Q_NULLPTR; ...  }" vs "{ Foo *f = 0; ... }"

Initialization of a pointer variable. Using preprocessor vs. perfectly
valid, unambiguous use of the C++ core languange.

The answers are, order of increasing surprise factor:

1) "I am not a big fan of nullptr, but it makes sense in a few places,
    and can " see the point in use Q_NULLPTR there."

    -- That's not (fully?) matching the case condition.


2) "it takes me a couple of milliseconds extra to comprehend what the 
    tooltip for QVariant's toInt() means:
      int toInt(bool *ok = 0) const;
    instead, if qvariant.h could be written using nullptr or Q_NULLPTR:
    It would increase the quality of Qt for me, at least."

    -- That's not matching the case condition at all.


3) "I find Q_NULLPTR *beautiful* (bautyful is deeper than pretty), "

    -- That's _could be_ meant to be matching the case condition (Thanks,
       Marc, for reading) but it is also the first time in the last 20
       years I saw someone calling the use of the preprocessor instead of
       a perfectly legal C++ idiom 

By now I have a hard time to understand how conflict resolution in this
model is supposed to work.

Any two approvers can commit whatever they want, introducing whatever personal
coding style they feel like?  Discussions that are meant to get consensus at
least about part of the problem are watered down by adding more and more
off-topic side track until "hopefully nobody cares anymore"?

Andre'