bug-commoncpp
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

error: use of undeclared identifier 'nullptr'


From: Ryan Schmidt
Subject: error: use of undeclared identifier 'nullptr'
Date: Fri, 24 May 2019 01:21:44 -0500

Hi, ucommon 7.0.0 fails to build on Mac OS X 10.7 and 10.8 with the version of 
Apple Clang provided by Xcode. The error is:

../inc/ucommon/platform.h:552:51: error: use of undeclared identifier 'nullptr'

Here are full build logs:

https://build.macports.org/builders/ports-10.7_x86_64_legacy-builder/builds/103277/steps/install-port/logs/stdio

https://build.macports.org/builders/ports-10.8_x86_64_legacy-builder/builds/95334/steps/install-port/logs/stdio

My understanding is that nullptr is a part of the C++11 standard. The default 
C++ standard library used on OS X 10.8 and earlier is the Apple GCC 4.2.1 
version of libstdc++, and it does not support C++11. The default C++ standard 
library used on OS X 10.9 and later is libc++, and it does support C++11.

Looking at platform.h, it appears to be going to some effort to support 
pre-C++11 platforms, so I think there may just be a mistake in how it's 
handling nullptr.

The build succeeds on Mac OS X 10.6 using its Apple GCC 4.2.1 compiler. 
Apparently the build correctly detects that this platform doesn't support 
nullptr so it doesn't try to use it (or rather, it defines a compatibility 
implementation). It also succeeds on OS X 10.9 and later using its Apple clang 
compiler, where nullptr is supported.

The condition used in platform.h to decide whether to define a compatibility 
implementation of nullptr is strange to me. It says:

#if __cplusplus <= 199711L && !defined(_MSC_VER)
#if ...
...
#elif !defined(__clang__) || (defined(__clang__) && defined(__linux__))

This seems to suggest a belief that clang works differently on Linux than it 
does on other platforms, which is inaccurate. Clang does, however, work 
differently depending on whether the C++ standard library it is used with 
supports C++11 or not. And even when C++11 mode has not been requested, clang 
appears to support nullptr as an extension as long as the C++ standard library 
supports nullptr.

So you need a different check than "defined(__linux__)" to determine if the 
compatibility nullptr is needed for clang, since it is also needed in some 
situations on macOS. For MacPorts, I have changed "defined(__linux__)" to 
"!defined(_LIBCPP_VERSION)" but I don't know if this is correct for other 
platforms. (On macOS, I know that only libc++ gives us C++11 support, but other 
platforms might use an updated version of libstdc++ containing C++11 support.) 
I have seen it suggested that __has_feature(cxx_nullptr) or 
__has_extension(cxx_nullptr) could be used, but I was not able to get that to 
work.



In addition, I would like to draw your attention back to this previous bug 
report:

http://lists.gnu.org/archive/html/bug-commoncpp/2017-10/msg00000.html

The patch provided there still needs to be committed to your repository. We are 
using a similar patch in MacPorts.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]