CocoaDev: NSNull

Correcting Anonymous Guy, it's /dev/null not /dev/null/ (which would be a directory)

NSNull last edited April 4, 2010 16:26:12 (189.190.248.143) CocoaDev is sponsored by: Panic: Shockingly good Mac software!
Edit / History / New / Search	Quick Links: Home / Recent Changes / Glossary / Jobs / Forums / Help
NSNull is the FoundationKit's equivalent of nil and NULL. It's used as a placeholder in collections which do not allow you to set an item to nil. See also: FoundationCollections Nothing is a concept that goes by many names: nil Nil NULL NSNull 0 zero nada zip zilch As you can see, it's a master of disguise. Handle with care. Don't forget the most ancient of all... /dev/null/ --Anonymous Guy If you're talking types, you can also add void. -- RobRix ... And false ... And none -- which coincidentally seems to be the point of this page... and [ ] (imagine nothing in the preceding box.) Correcting Anonymous Guy, it's /dev/null not /dev/null/ (which would be a directory) The difference of course is that they're not all semantically equivalent. NULL is defined to be a 0x00 byte, while nil is any invalid object pointer which might or might not equall NULL depending on the implementation. This rooted in the fact that it is convention to denote False with zero and True with one, a completely arbitrary choice. It's somewhat misleading because False does no inherently mean Nothing, but they've become somewhat linked due to notational convention. --OwenAnderson It's not clear exactly what is meant here by "nil is any invalid object pointer" -- `nil` is certainly not the same as a pointer to, for example, a freed object. It is certainly the case, however, that `nil` is not the same as `false` or `NO`. `[NSNull null]` is a singleton value used to represent a `nil` value in a situation which prohibits the use of `nil` -- for example in a collection class. And NULL is not "defined to be a 0x00 byte." It's defined to be an alias for the null pointer, which while equivalent to 0 on most architectures, is not portably so. Not to mention that it's pointer-width, not byte-width. As for the `nil` statements made above, I am pretty sure `nil` in fact is zero (with pointer size). At least the ObjC docs say it is defined as `(id) 0` and somewhere else it is stated that is equivalent to `NULL`. If this were not the case, something like `if (object)` would not work. --MarCocoa `nil` just happens to be zero, but it's not guaranteed as such. The C standard guarantees that `NULL` will be zero when you convert it to an integer, and that it will compare as equal to zero, but it does not guarantee that the actual `NULL` pointer itself contains zero. `nil` is just `NULL` by another name, so it'll follow those rules as well. That said, you won't find any modern architecture on which `NULL` is not implemented as zero. As we probably all agree, it is utterly unimportant and purely theoretical, but as said, the Objective-C Language Reference by Apple states that `nil` is defined as `(id) 0` and not as `(id) NULL` ... And converting the integer zero to a pointer type gets you, guess what, `NULL`. The language standard guarantees that `(id)0` is equivalent to `NULL` except for the type.
Edit / History / New / Search	Quick Links: Home / Recent Changes / Glossary / Jobs / Forums / Help

The difference of course is that they're not all semantically equivalent. NULL is defined to be a 0x00 byte, while nil is any invalid object pointer which might or might not equall NULL depending on the implementation. This rooted in the fact that it is convention to denote False with zero and True with one, a completely arbitrary choice. It's somewhat misleading because False does no inherently mean Nothing, but they've become somewhat linked due to notational convention. --OwenAnderson

It's not clear exactly what is meant here by "nil is any invalid object pointer" -- nil is certainly not the same as a pointer to, for example, a freed object. It is certainly the case, however, that nil is not the same as false or NO.

[NSNull null] is a singleton value used to represent a nil value in a situation which prohibits the use of nil -- for example in a collection class.

And NULL is not "defined to be a 0x00 byte." It's defined to be an alias for the null pointer, which while equivalent to 0 on most architectures, is not portably so. Not to mention that it's pointer-width, not byte-width.

As for the nil statements made above, I am pretty sure nil in fact is zero (with pointer size). At least the ObjC docs say it is defined as (id) 0 and somewhere else it is stated that is equivalent to NULL. If this were not the case, something like if (object) would not work.

nil just happens to be zero, but it's not guaranteed as such. The C standard guarantees that NULL will be zero when you convert it to an integer, and that it will compare as equal to zero, but it does not guarantee that the actual NULL pointer itself contains zero. nil is just NULL by another name, so it'll follow those rules as well. That said, you won't find any modern architecture on which NULL is not implemented as zero.

As we probably all agree, it is utterly unimportant and purely theoretical, but as said, the Objective-C Language Reference by Apple states that nil is defined as (id) 0 and not as (id) NULL ...

And converting the integer zero to a pointer type gets you, guess what, NULL. The language standard guarantees that (id)0 is equivalent to NULL except for the type.