Objective-C and C++0x nullptr

Clang Frontend
#1

Hello,

while naively replacing NULL with nullptr in my code, I stumbled upon the following. Take this
program:

@interface NSOpenGLPixelFormat
{
}
@end

int main(int, char**)
{
  NSOpenGLPixelFormat* p = 0;
  if (p == nullptr)
    ;
}

When compiling this with clang r131897 and -x objective-c++, clang produces the following error:
"invalid operands to binary expression ('NSOpenGLPixelFormat *' and 'nullptr_t')"

Now, nullptr is a C++0x constant, and NSOpenGLPixelFormat is an Objective C class, but a pointer
to it is still a pointer and thus should be comparable against nullptr.

I think. Although I don't think the interaction between Objective-C and C++0x has been defined
(yet).

What do *you* think?

With many thanks in advance,
Jonathan

#2

Clang handles pointers to ObjC types and normal types differently. That said, it would make sense to make nullptr be a proper ObjC pointer null constant as well. This would obviously be a language extension. If you want this, you should open a feature request in bugzilla.

Sebastian

#3

while naively replacing NULL with nullptr in my code, I stumbled upon the following.

You shouldn't need to do that. NULL should be a #define for nullptr in C++ 2011 mode, or for something more relevant to the language settings in other modes.

Now, nullptr is a C++0x constant, and NSOpenGLPixelFormat is an Objective C class, but a pointer
to it is still a pointer and thus should be comparable against nullptr.

I think. Although I don't think the interaction between Objective-C and C++0x has been defined
(yet).

What do *you* think?

I would expect it to behave in exactly the same way as GCC's __null (which is what NULL currently expands to for me), which can be assigned to Objective-C pointers. I'm a little bit surprised that it doesn't...

David

-- Sent from my IBM 1620

#4

Hello,

while naively replacing NULL with nullptr in my code, I stumbled upon the following.

You shouldn't need to do that. NULL should be a #define for nullptr in C++ 2011 mode, or for something more relevant to the language settings in other modes.

Well, I was trying to initialize a std::unique_ptr with an explicit NULL, which resulted in an
ambiguity during overload resolution of the constructor (there is one taking a nullptr_t as well
as one taking a T*). So I took that opportunity to convert this part of my code base to C++0x,
too (and use std::unique_ptr's default constructor ...).

Clang's behaviour seems to be correct here, as according to FDIS 4.10p1, "0L" can be converted to a
pointer type as well as a std::nullptr_t.

Reading FDIS 18.2p3, it does not seem that NULL is required to be a #define for nullptr. Indeed, the
footnote there explains that "0" is a valid definition (and libc++ currently uses the system's
stddef.h's definition).

Jonathan

#5

Yep, this just sounds like a bug due to how we represent objective c types internally. Please file a bugzilla.

-Chris

#6

Hello,

Yep, this just sounds like a bug due to how we represent objective c types internally. Please file a bugzilla.

Consider it done: PR10052.

Jonathan