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

Knoll Lars Lars.Knoll at theqtcompany.com
Wed Feb 11 11:53:09 CET 2015

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
>or else (except where it causes a warning), even though a few lines up
>seem to allow replacing it "where it makes things clearer" (whatever that

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
>the first 0 could be replaced with Q_NULLPTR to indicate that yes we know
>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.


More information about the Development mailing list