Blink is already using nullptr extensively via emulation. This would have relatively small impact on most of the Blink codebase except for in places where the WTF emulation can't be used, such as the Blink public c++ api, where the impact will probably be fairly small.
- James
* We won't mass-replace NULL with nullptr (only one person asked for this, it makes blame output harder to parse, and lines containing NULL are often tricky and interesting in blame output).
(Another issue that I just learned about that makes this difficult is that the Windows code uses NULL heavily in places where no pointer is expected – several of the HANDLE types (not HANDLE itself I believe, but e.g. TRACEHANDLE), and MSDN even says to use NULL for those (http://msdn.microsoft.com/en-us/library/windows/desktop/aa363686(v=vs.85).aspx). This would probably make a mass find-and-replace somewhat involved too.)
--
In this case, maybe we can have a clang plugin/reformatter that identifies places where NULL is actually used as a pointer (like when it is immediately implicitly converted)... and maybe also cases where it is used as a sentinel vararg :). This wouldn't get all cases, but would probably get most while still being reasonable safe.
PK
If we can do a machine conversion I think we should, but I'm not entirely sure this will be easy. I don't want to block usage of the feature on their being a good rewriter. For example, we'll have to reformat many lines of code since nullptr is 3 characters longer which might be tricky in parts of the codebase that aren't currently clang-formatted.How about we allow nullptr, encourage conversion, and if somebody cooks up a workable translator we allow using it but we do not make that a condition of use of the feature?- James
On Wed, Sep 24, 2014 at 2:15 PM, Chris Hopman wrote:
I think I agree with Peter. As we introduce new features, particularly when we are going to say that you should use the new way and not the old way, I think we should prefer to mass rewrite things to use the new way, even if it comes at some cost in churn/blameability. That being said, for cases where the conversion is complicated, then just a having a policy of converting code as it is changed/introduced/etc may be fine.In this case, maybe we can have a clang plugin/reformatter that identifies places where NULL is actually used as a pointer (like when it is immediately implicitly converted)... and maybe also cases where it is used as a sentinel vararg :). This wouldn't get all cases, but would probably get most while still being reasonable safe.
On Wed, Sep 24, 2014 at 2:02 PM, 'Peter Kasting' via Chromium-dev wrote:
TRACEHANDLE is ULONG64, so that one won't compile after the replace. Besides, we should probably replace it with =0 instead. I did a quick look, there looks to only be a few places where it needs to be fixed, so a mass replace, compile, and fix should be fine for this one.
If we can do a machine conversion I think we should, but I'm not entirely sure this will be easy. I don't want to block usage of the feature on their being a good rewriter. For example, we'll have to reformat many lines of code since nullptr is 3 characters longer which might be tricky in parts of the codebase that aren't currently clang-formatted.
How about we allow nullptr, encourage conversion, and if somebody cooks up a workable translator we allow using it but we do not make that a condition of use of the feature?
clang-modernize has a transform for this: http://clang.llvm.org/extra/UseNullptrTransform.html