I think it’s because an NSArray is immutable such that an empty array is
guaranteed to never change. This gives the compiler opportunities for
optimization based on this knowledge.
It starts to get interesting when you do things like:
NSArray *emptyArray = [[NSArray alloc] init];
NSArray *anotherArray = [emptyArray arrayByAddingObject:anObject];
But this creates a new array. Consequently, any meaningful array won’t be the
one created with [[NSArray alloc] init].
> On Sep 21, 2016, at 9:19 PM, Jeff Evans <jev...@ars-nova.com> wrote:
> Whoa - maybe I've had too much wine with dinner, but:
> Is it really true what Jens says, that [[NSArray alloc]init] always
> returns the same pointer?
> If that is the case, how can one declare two separate arrays?
> On Sep 21, 2016, at 8:50 PM, Jens Alfke wrote:
>> On Sep 21, 2016, at 6:36 PM, Graham Cox <graham....@bigpond.com> wrote:
>> Which is yet another reason why void* is such a shitty concept. Apple could
>> easily have insisted that parameter was id<NSObject> without any real
>> problems, so void*… sheesh.
> It’s not an object! It’s just an opaque ‘cookie’ that you can use to
> recognize which observer is being invoked, and specify which one to remove.
> The point of using a void* is that it’s easy to generate guaranteed-unique
> values by taking the address of a static variable. If the context were an
> object, people would be likely to assume they should use -isEqual: to compare
> them (as half the people on this thread seem to be doing), but that’s not a
> good idea because it can result in false positives comparing
> equal-but-different objects.
> Moreover, it can be hard to be sure whether you’re getting distinct objects
> in Obj-C, since initializers will often return unique singletons for common
> cases. For instance, [[NSArray alloc] init] will always return the same
> pointer every time it’s called, making it a terrible choice for a context.
Cocoa-dev mailing list (Cocoafirstname.lastname@example.org)
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 arch...@mail-archive.com