Re: !foo vs foo == nil
Re: !foo vs foo == nil
- Subject: Re: !foo vs foo == nil
- From: Sam Mo <email@hidden>
- Date: Thu, 21 Aug 2008 07:57:43 -0400
On Aug 21, 2008, at 4:47 AM, Thomas Engelmeier wrote:
Am 21.08.2008 um 05:03 schrieb Michael Ash:
There was a common perception that NULL is not really the same
as nil. But
seems like in the end it really is (void*)0.
They differ in type, not in value.
"NULL" is (void *) 0.
"nil" is (id) 0.
"Nil" is (Class) 0.
This is true conceptually but not as far as their actual definition.
NULL can be either 0 or (void *)0.
Let's be a little bit more precise, I'll try to paraphrase
correctly from my memory:
a.)
(int) NULL is NOT required or guaranteed 0x0 by the standard.
This is why one should never use
if( anPtr == (void *) 0 );
instead of
if( anPtr == NULL );
On modern machines, it usually is.
But Stroustrup says NULL is defined as 0 (zero) in C++.
<http://www.research.att.com/~bs/bs_faq2.html#null>
With my C++ background, I normally write:
if (thePtr) {
// do things
}
else {
// error handling
}
Btw, I recall reading something in the PPC days that the expected
case should put first so the compiler can optimize better (branch
prediction?).
b.) At least the C++ standard mandates for type conversion of an
pointer to an boolean, that e.g. ( !anPtr ) is equivalent to ( !
(anPtr == NULL )). I didn't read the C99 spec but I'm sure there is
something similar specified.
This implementation detail does probably not matter on most
platforms today as even microcontrollers have AFAIK linear address
spaces.
When I was writing my first C app on a DOS machine, there were
segmented addresses. That meant it could happen that
((somePtr + offset) - offset) == somePtr
evaluated to false - (somePtr + offset) changed the segment,
anotherPtr - offset did not. Big debug surprise for poor little
68020 fanboy ;-)
Regards,
Tom_E
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden