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

[Knoll Lars]

On 11/02/15 10:46, "Marc Mutz" <marc.mutz at kdab.com> wrote:

>On Wednesday 11 February 2015 08:27:24 Knoll Lars wrote:
>> To settle this, I am also with Andre and Simon.
>
>Please don't evade: how is the situation different for emit vs. Q_NULLPTR?

emit IMO helps code readability, as you know this is not a regular
function call but a signal emission. Having said that I don’t think we
have a strong requirement to use it.
>
>> let’s not go and replace 0 with the macro in places where
>> things are unambiguous.
>
>For old code, by definition, 0 as currently used cannot be ambiguous
>(since it 
>compiled before).
>
>Ergo, you're banning replacing any 0 with nullptr in existing code, in
>passing 
>or else (except where it causes a warning), even though a few lines up
>you 
>seem to allow replacing it "where it makes things clearer" (whatever that
>means).

Unambiguous to somebody reading the code, not the compiler. There is a
difference between them.

>For new code, we're not replacing a 0.
>
>To me that reads that it's fine to use Q_NULLPTR in new code, even though
>a few 
>lines up you say that you dislike macros.
>
>Can you leave less wiggle room, please? :)

Well, I think Thiago already summed it up nicely:

>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.


Readability and making sure a human can parse the written code quickly is
important to me. And less macros usually do make the code more readable.
But where things are ambiguous to a human reading the code (again, that’s
different from a compiler), I’m fine with using Q_NULLPTR to clarify.

Cheers,
Lars