Bug 47756 – Make a nullptr that works with OwnPtr and RefPtr

• Component: Web Template Framework
• Status: RESOLVED FIXED

[Darin Adler]

Make a nullptr that works with OwnPtr and RefPtr

[Darin Adler]

Created attachment 70924 [details]
Patch

[Geoffrey Garen]

Comment on attachment 70924 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=70924&action=review

> JavaScriptCore/wtf/NullPtr.h:34
> +class nullptr_t { };

Would it be better to #ifndef nullptr_t here, to avoid overriding something if it is provided by the compiler?

r=me

[Anders Carlsson]

View in context: https://bugs.webkit.org/attachment.cgi?id=70924&action=review

> JavaScriptCore/wtf/NullPtr.h:35
> +extern nullptr_t nullptr;

To better match the C++0x standard, nullptr_t should be in the std namespace.

> JavaScriptCore/wtf/OwnArrayPtr.h:77
> +    OwnArrayPtr& operator=(const nullptr_t&) { clear(); return *this; }

It would be better if nullptr_t was always passed by value. (For example, the Itanium ABI just ignores empty classes when they're passed by value).

[Darin Adler]

(In reply to comment #2)
> Would it be better to #ifndef nullptr_t here, to avoid overriding something if it is provided by the compiler?

If nullptr_t was a macro, then yes. But it’s not.

[Darin Adler]

(In reply to comment #3)
> To better match the C++0x standard, nullptr_t should be in the std namespace.

Fixed.

> It would be better if nullptr_t was always passed by value. (For example, the Itanium ABI just ignores empty classes when they're passed by value).

Fixed.

[Darin Adler]

Committed r69970: <http://trac.webkit.org/changeset/69970>

[WebKit Review Bot]

http://trac.webkit.org/changeset/69970 might have broken Qt Windows 32-bit Release

[Kenneth Rohde Christiansen]

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf details a different enumation of nullptr:

const // this is a const object...
class {
public:
  template<class T> // convertible to any type
    operator T*() const // of null non-member
{ return 0; } // pointer...
  template<class C, class T> // or any type of null
    operator T C::*() const // member pointer...
{ return 0; }
private:
  void operator&() const; // whose address can't be taken
} nullptr = {}; // and whose name is nullptr

Does your implementation work in all these situations?

[Darin Adler]

(In reply to comment #8)
> Does your implementation work in all these situations?

No. I don’t think it’s possible to make one that would.

This implementation lets us use nullptr in a limited way in the long time between now and when all compilers used with WebKit have nullptr support.

[Darin Adler]

(In reply to comment #9)
> (In reply to comment #8)
> > Does your implementation work in all these situations?
> 
> No. I don’t think it’s possible to make one that would.

Oops, I misunderstood your question.

I think we can definitely put the fancier nullptr_t and nullptr in.