On 2015-12-09 10:14, Marc Mutz wrote: > in 5.7, nullptr (Q_C_NULLPTR) is required to be supported by the compiler, > but > there are no guidelines as to its use in the coding conventions (to the > extent > they need to be in there). > > I propose the following, based on Thiago's proposal from January this year, > considering the new situation that we now require nullptr support in the > compiler: > [...] > - compilers that have it, will have -Wzero-as-nullptr-constant added during > headersclean[0]
Yay! :-) Yes, please, for exactly the reason you gave. > - APIs that require the use of nullptr for disambiguation are discouraged, > but may be acceptable to be decided on a case-by-case basis. On that note, there *is* one case in which '0' as nullptr makes sense... default values for QFlags. A literal '0' "looks like" an empty bitset much more than 'nullptr', even though IIRC it actually ends up implemented via a void* ctor. This probably means that those should be changed to use '{}' as the default initializer instead (i.e. not 'nullptr'). I'm not sure what this means for compiler support (i.e. if any compilers that Qt still supports don't support it), though I do know offhand it does exclude GCC < 4.7. (Alternatively, there could be a qNullFlag or some such, but that might have compatibility problems.) > Arguments against: > - it's uglier than "0", and more to type FWIW, I'm with Sergio here; not sure I agree about it being "uglier"... it's certainly more obvious that 'nullptr' is... a null pointer, and not an integer literal... (And, likewise, I'm more sympathetic to '0' vs. 'Q_NULLPTR'. But since that's not what we're talking about...) -- Matthew _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development