> self = [super init];
> if (self)
> {
> }
> return self;
>
> self = [super init];
> if (self != nil)
> {
> }
> return self;
>
> The Xcode samples promote the first variant, but I'm wondering if the
> second one is more correct?
No. The more common convention in (Apple's) ObjC is to use implicit boolean
values, though an explicit test against nil is fine if that's your preference.
> The "nil" is defined as follows (jumped to definition)
>
> #define nil NULL
> #define NULL ((void*)0)
I'd hazard to say that's an implementation detail. While you can compare
object pointers against NULL, it's strongly against convention - you use nil
for pointers to ObjC objects, NULL for other types of pointers. Hypothetically
this protects you from any future changes in how objects are distinguished from
"regular" pointers.
> I also heard that generally speaking NULL is not necessarily always
> equal to 0 on all architectures.
That definition is quite archaic. Though technically speaking it's true, and
is thus an argument for actually using NULL rather than 0, it's not the only
such argument by far*, and in any case there's enough momentum behind NULL == 0
that this will almost certainly never change.
* = For example, more important arguments are for readability in code, and
because 0 is an integer whereas pointers are not. And that a test against zero
is faster than a test against any other specific integer on all modern hardware.
_______________________________________________
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
