On 11/02/15 10:46, "Marc Mutz" <marc.m...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
