> The next step is to s/nsnull/nullptr/ in the codebase, and get rid of nsnull.
Forgive my ignorance, but how does this affect NULL? Would that be deprecated in favor of nullptr as well? Should we use nsnull instead of NULL in new code, in anticipation of the nsnull --> nullptr switch? -Justin On Wed, Jul 25, 2012 at 5:45 AM, Aryeh Gregor <a...@aryeh.name> wrote: > The C++11 standard defines a new dedicated null-pointer symbol, "nullptr". > It provides better type-safety than existing null-pointer definitions, > because it doesn't allow implicit conversion to numeric types. In > <https://bugzilla.mozilla.org/show_bug.cgi?id=626472> I defined "nullptr" to > mean 0L/0LL (like current nsnull) where unsupported, then redefined "nsnull" > to mean "nullptr". This caught a bunch of places where people were using > nsnull to mean crazy things like NS_OK or other things that happened to equal > 0. > > The next step is to s/nsnull/nullptr/ in the codebase, and get rid of nsnull. > There's no reason for us to use our own identifier when there's a standard > one. This will be of comparable scale to the PRBool elimination of last year > -- around 20,000 lines changed instead of 30,000. This will of course > insta-bitrot any patches that people have that mention "nsnull" anywhere, but > a shell script will be provided to auto-fix them, as with the PRBool switch > (something like "sed -i s/\bnsnull\b/nullptr/ .hg/patches{,-*}/*" should do > it). > > This message is of general interest because after the switch, "nsnull" will > no longer work, and patch queues will have to be updated. Also, anyone who > maintains a branch will want to figure out how to avoid merge pain. > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
