[webkit-dev] Potential patch for building webkit on Visual Studio 2010

[Jean-Luc Brouillet]

A more general discussion is how compatible with C++ 0x WebKit intends to be.

The problem Jake mentioned is caused by the RefPtr class.  When faced with:
        RefPtr<Node> node;
        node = 0;
the VS2010 compiler can't tell whether to cast the integral 0 to
nullptr_t or to T*, e.g. to use either
        RefPtr& operator=(T*);
        RefPtr& operator=(std::nullptr_t) { clear(); return *this; }

If WebKit developers intend the code to be tracking C++ 0x, changing
the assignments to use nullptr would be forward thinking.   If not, I
expect we could #ifdef out "operator=(std::nullptr_t)".

I'm new to the WebKit list, so apologies if this broader discussion
should also be done within the bug tracking system.

Jean-Luc

On Wed, Dec 15, 2010 at 8:38 AM, Adam Roben <aroben at apple.com> wrote:
>
> On Dec 14, 2010, at 8:24 PM, Jake wrote:
>
> Hello,
> I've made some changes to the webkit trunk that allows me to build webkit
> (more specifically QtWebkit) with Visual Studio 2010. I had to make several
> changes to handle the ambiguous operator = error from NullPtr.h.
> To get the build to work I made two primary changes:
> First, NullPtr.h
> #ifndef NullPtr_h
> #define NullPtr_h
> // For compilers and standard libraries that do not yet include it, this
> adds the
> // nullptr_t type and nullptr object. They are defined in the same
> namespaces they
> // would be in compiler and library that had the support.
> #if !defined(_MSC_VER)
> #ifndef __has_feature
>     #define __has_feature(feature) 0
> #endif
> #if !__has_feature(cxx_nullptr)
> namespace std {
>     class nullptr_t { };
> }
> extern std::nullptr_t nullptr;
> #endif
> #elseif  _MSC_VER < 1600
> //to maintain compatibility with previous versions of msvc
> #ifndef nullptr
> #define nullptr 0
> #endif
> #endif //_MSC_VER
> #endif
>
> And secondly I changed all = 0 errors to = nullptr (approximately 450
> instances).
> My question is, does this look like a sound approach? If so, I'll submit a
> patch.
>
> It would be great to move this discussion to bugs.webkit.org, even if you
> aren't sure of the exact correct approach yet. Please file a bug there and
> attach your patch so that contributors can discuss it.
> -Adam
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>