On Feb 24, 2012, at 15:26 , Scott Ribe wrote:
> Thing is: if(foo) is equivalent to if(foo != 0), which I think results in 0
> being treated as a pointer, not the pointer being cast to int, anyway if
> if(foo) could fail, so could if(foo != 0)... Also I think "Except as
> previously specified..." covers the case that NULL pointers convert to int
> 0...
The following two source code patterns are *exactly* identical to the C
compiler, *regardless of the type of 'foo'*:
1. if (foo)
2. if (foo != 0)
Additionally, if 'foo' is any kind of pointer, then a third pattern is
*exactly* identical to the first two:
3. if (foo != (void*) 0)
In Obj-C, the following are *exactly* identical to the third one (again,
assuming 'foo' is a pointer):
4. if (foo != nil)
5. if (foo != NULL)
Thus, there's absolutely no technical reason not to use all 5 of these
interchangeably for pointers. It's just a question of coding preference
(including putting the constant on the left of the operator, which was
discussed earlier in the thread, making a total of 9 equivalent coding
patterns).
These equivalences [under the restrictions stated above] have *nothing* to do
with the internal bit-pattern representation of a null pointer. There are *no*
implementation dependencies in any of them, assuming a compliant C compiler
like GCC or clang.
The *only* place where the internal bit-pattern matters, and where there might
be implementation dependent behavior, is source code where a pointer
sub-expression is mixed with a non-constant-evaluating-to-zero arithmetic
sub-expression. So all of this angst is wasted effort. :)
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
