Re: [C++0x] nullptr

[Jason Merrill <jason at redhat dot com>]

On 03/28/2010 05:52 PM, Magnus Fromreide wrote:
> The problem is when you compare it to
>
> template<class T>  void foo(T*); // #1
> void foo(nullptr_t); // #2
>
> where nullptr_t is a better match for foo(0).

Right, but this happens because deduction fails for #1.

> I think the overload resolution should be
>
>       1. int
>       2. nullptr_t
>       3. any pointer type
>
> but that it probably better discussed over at comp.std.c++.

Indeed.  :)

> I found out that the problem was that each pattern only match once
> so I had to add one more dg-message as follows
>
> char* k(char*);/* { dg-message "note" } { dg-message "note" } */

Really?  I haven't had to do that for multiple errors on the same line.

> > > +      if (TREE_CODE (intype) == NULLPTR_TYPE)
> > > +        return build_int_cst (type, 0);
> >
> > Why not fall through to cp_convert in this case?
>
> cp_convert in effect performs static_cast<target>(source), in this case
> that would be static_cast<integer-type>(nullptr) but that conversion
> isn't valid except when integer-type is bool.
>
> Removing this part triggers the following unexpected errors in the test
> suite:
>
> /usr/local/src/gcc/trunk/gcc/testsuite/g++.dg/cpp0x/nullptr04.C:8:55:
> error: aggregate value used where an integer was expected
> /usr/local/src/gcc/trunk/gcc/testsuite/g++.dg/cpp0x/nullptr04.C:9:31:
> error: aggregate value used where an integer was expected

Hmm, OK.

> Does GCC mangle the same on all platforms and ignore the mangling of the
> default platform compiler?

Yes.

> Now the missing parts are a lot smaller - there is no support for output
> of nullptr's (as opposed to nullptr_t's) but i do not see how to
> generate a nullptr either

Yeah, I don't think we need to worry about that; nullptr is a symbolic 
constant, not a declaration.  Debuggers can just learn to recognize 
"nullptr" directly without it being in the debug info.

> and there are still a bunch of missing debug output formats.

I think it's fine to treat nullptr_t as an integral type for other formats.

I'll look at the new patch in a bit.

Jason