NULL and nullptr and nil and Nil and NSNull

[[129295]]

The declarations of NULL and nullptr can be found in the stddef.h file of Clang 6.0:

 #undef NULL
 #ifdef __cplusplus
 # if !defined(__MINGW32__) && !defined(_MSC_VER)
 #define NULL __null
 # else  
 #define NULL 0  
 # endif
 # else  
 # define NULL (( void *) 0 )
 #endif
 #ifdef __cplusplus
 # if defined(_MSC_EXTENSIONS) && defined(_NATIVE_NULLPTR_SUPPORTED)
 namespace std { typedef decltype(nullptr) nullptr_t; }
 using ::std::nullptr_t;
 #endif
 #endif

As early as 1972, when the C language was first created, the constant 0 had a dual identity as a constant and a null pointer. C used the preprocessor macro NULL to represent a null pointer, allowing NULL and 0 to represent a null pointer and the constant 0, respectively. NULL can be defined as ((void*)0) or 0.

C++ does not follow the rules of C and does not allow implicit conversion of void* to other types of pointers. In order for the code char* c = NULL; to compile, NULL can only be defined as 0. This decision makes it impossible to distinguish the semantics of the code when overloading functions:

 void foo( char *);
 void foo( int );

C++ suggests that NULL should be defined as 0, so foo(NULL); will call foo(int), which is not what the programmer wants and violates the intuitiveness of the code. The ambiguity of 0 causes confusion here.

C++11 introduces a new keyword to represent the null pointer constant: nullptr, which separates the concept of null pointer from the integer 0. The type of nullptr is nullptr_t, which can be implicitly converted to any pointer or member pointer type, and can also be compared with them for equality or inequality. However, nullptr cannot be implicitly converted to an integer, nor can it be compared with an integer.

For backward compatibility, 0 can still represent the null pointer constant.

 char * pc = nullptr; // OK  
 int * pi = nullptr; // OK  
 int i = nullptr; // error   
   
 foo(pc); // calls foo(char *)  

PS: __MINGW32__ is a predefined macro for MinGW compiler. _MSC_VER is a predefined macro for Microsoft C/C++ compiler - cl.exe when compiling code. The value of _MSC_VER indicates the version of cl. This macro can also be used for conditional compilation when you need to write code for a specific version of cl.

nil and Nil

Objective-C

nil is defined as a null instance.

Nil is defined as the empty value of a class object (a null class)

nil and Nil have equivalent declarations in objc.h and MacTypes.h files:

 #ifndef Nil  
 # if __has_feature(cxx_nullptr)  
 #define Nil nullptr  
 # else  
 #define Nil __DARWIN_NULL  
 # endif  
 #endif  
 #ifndef nil  
 # if __has_feature(cxx_nullptr)  
 #define nil nullptr  
 # else  
 #define nil __DARWIN_NULL  
 # endif  
 #endif  

According to the description of __has_feature in Clang 3.7 document: "__has_feature evaluates to 1 if the feature is both supported by Clang and standardized in the current language standard or 0 if not", __has_feature(cxx_nullptr) is used to determine whether the nullptr feature in C++11 is supported. In Objective-C, both nil and Nil are defined by the __DARWIN_NULL macro. Press CMD and click to enter _types.h:

 #ifdef __cplusplus
 #ifdef __GNUG__
 #define __DARWIN_NULL __null
 # else   /* !__GNUG__ */  
 #ifdef __LP64__
 #define __DARWIN_NULL (0L)
 # else   /* !__LP64__ */  
 #define __DARWIN_NULL 0  
 #endif /* __LP64__ */  
 #endif /* __GNUG__ */  
 # else   /* !__cplusplus */  
 #define __DARWIN_NULL (( void *) 0 )
 #endif /* __cplusplus */  

Because Objective-C is not C++ code, the second to last line #define __DARWIN_NULL ((void *)0) is highlighted, which means that the final nil and Nil are essentially ((void *)0)

PS: In fact, if you only look at nil and Nil definition in Objective-C, it is not so troublesome. Just check "Constants->Null Values" in Objective-C Runtime Reference.

Swift

Swift 1.2 currently only has nil but no Nil. For security reasons, Swift has added the Optional type as a container. It's like a box that may contain a certain type of object, or it may be empty (nil). Boxes can also be nested or removed, but this is all based on safe parsing, binding, etc. Swift's nil is not the same as nil in Objective-C. In Objective-C, nil is a pointer to a non-existent object. In Swift, nil is not a pointer - it is a definite value used to indicate the absence of a value. Any type of optional value can be set to nil, not just object types.

PS: For more information about Optional types in Swift, please refer to my other blog post: Optionals and Optional Chaining in Swift

PS: Once upon a time, Swift’s nil was not a literal, but a unique instance of the NilType type. But that’s all history now.

NSNull

The definition of NSNull in NSNull.h is:

 @interface NSNull : NSObject <nscopying, nssecurecoding>
 + (NSNull *)null;
 @end</nscopying, nssecurecoding>

NSNull is a singleton with only one method, null, and is also used to represent null values. However, it appears in some scenarios where nil cannot be used to represent null values. For example, in NSArray and NSDictionary, nil represents the end of the array or dictionary (even if nil does not appear at the end, it will be cut off and the value after nil will be lost). In this case, only NSNull objects can be used to represent null values:

 NSNull *nullValue = [NSNull null ];
 NSArray *arrayWithNull = @[nullValue];
 NSLog(@ "arrayWithNull: %@" , arrayWithNull);
 // Output: "arrayWithNull: (<null>)"</null>  

Although NSNull is semantically equivalent to nil, it is not exactly equal to nil:

 id aValue = [arrayWithNull objectAtIndex: 0 ];
 if (aValue == nil) {
 NSLog(@ "equals nil" );
 }
 else   if (aValue == [NSNull null ]) {
    NSLog(@ "equals NSNull instance" );
 if ([aValue isEqual:nil]) {
        NSLog(@ "isEqual:nil" );
 }
 }
 // Output: "equals NSNull instance"