DO NOT COMMIT: NullPtr support

DO NOT COMMIT: NullPtr support

BUG=none

[Ryan Sleevi, 2012-12-03 17:58:44]

awong: This is FYI as the culmination of the nullptr experiments. 

What you don't see is what was ruled out - using the WK type directly (layering
violation), using WK's approach of sticking it in std:: (ODR violation), nor
using WK's approach of merely using a type tag (empty struct) rather than a
convertable type.

It does not compile on Win (which I figure will be the most strict) due to
ambiguity with overload resolution

d:\src\chromium\public\src\base\memory\scoped_vector_unittest.cc(64) : error C26
68: 'scoped_ptr<C>::scoped_ptr' : ambiguous call to overloaded function
        with
        [
            C=`anonymous-namespace'::LifeCycleObject
        ]
        d:\src\chromium\public\src\base\memory\scoped_ptr.h(150): could be 'scop
ed_ptr<C>::scoped_ptr(C *)'
        with
        [
            C=`anonymous-namespace'::LifeCycleObject
        ]
        d:\src\chromium\public\src\base\memory\scoped_ptr.h(145): or       'scop
ed_ptr<C>::scoped_ptr(std::nullptr_t)'
        with
        [
            C=`anonymous-namespace'::LifeCycleObject
        ]
        while trying to match the argument list '(int)'

If you look in the MSVCRT sources, <functional> does some SFINAE hacks to
exclude integral constants from resolving, which may work for scoped_ptr(C*) by
making it

template <typename F> scoped_ptr(F), ensuring that is_convertable<F,C*> and that
!is_integral<F>. 

This mostly works by forcing template resolution to re-prioritize the order of
overload resolution.

I haven't had time to revisit that, and to hack around MSVC's templates.

[awong, 2012-12-04 20:42:44]

Good news is we can probably use std::nullptr on MSVC given the MSVC 2010
baseline now.

However, currently discussing Linux toolchain support on a separate thread which
might obviate this discussion.

-Albert


On 2012/12/03 17:58:44, Ryan Sleevi wrote:
> awong: This is FYI as the culmination of the nullptr experiments. 
> 
> What you don't see is what was ruled out - using the WK type directly
(layering
> violation), using WK's approach of sticking it in std:: (ODR violation), nor
> using WK's approach of merely using a type tag (empty struct) rather than a
> convertable type.
> 
> It does not compile on Win (which I figure will be the most strict) due to
> ambiguity with overload resolution
> 
> d:\src\chromium\public\src\base\memory\scoped_vector_unittest.cc(64) : error
C26
> 68: 'scoped_ptr<C>::scoped_ptr' : ambiguous call to overloaded function
>         with
>         [
>             C=`anonymous-namespace'::LifeCycleObject
>         ]
>         d:\src\chromium\public\src\base\memory\scoped_ptr.h(150): could be
'scop
> ed_ptr<C>::scoped_ptr(C *)'
>         with
>         [
>             C=`anonymous-namespace'::LifeCycleObject
>         ]
>         d:\src\chromium\public\src\base\memory\scoped_ptr.h(145): or      
'scop
> ed_ptr<C>::scoped_ptr(std::nullptr_t)'
>         with
>         [
>             C=`anonymous-namespace'::LifeCycleObject
>         ]
>         while trying to match the argument list '(int)'
> 
> If you look in the MSVCRT sources, <functional> does some SFINAE hacks to
> exclude integral constants from resolving, which may work for scoped_ptr(C*)
by
> making it
> 
> template <typename F> scoped_ptr(F), ensuring that is_convertable<F,C*> and
that
> !is_integral<F>. 
> 
> This mostly works by forcing template resolution to re-prioritize the order of
> overload resolution.
> 
> I haven't had time to revisit that, and to hack around MSVC's templates.

[Ryan Sleevi, 2012-12-05 04:05:32]

awong: More ugly hackiness, but this now disambiguates.

The problem was the compiler trying to determine which overload to call, in the
set of 

scoped_ptr(std::nullptr_t)
scoped_ptr(C*)

When invoked as scoped_ptr(NULL). This is because NULL is treated as the
integral constant 0, which is convertible to both C* and std::nullptr_t

This is, ultimately, a giant hack. We could just as well allow scoped_ptr(int)
and hide scoped_ptr(C*) using similar SFINAE, and avoid the whole base::NullPtr
bruaha.

we'd also have to pull in the tr1::type_traits into our local type traits, this
was just being lazy and showing the PoC.