On Sep 21, 2016, at 21:10 , Doug Hill <cocoa...@breaqz.com> wrote:
> I believe the original question was why you can compare a string literal to
> another object pointer using the == operator and it somehow works.
Actually, we’re more or less on the same page here, but for posterity…
There’s no “somehow” with the == operator. It’s a C thing, not an Obj-C thing,
so putting it between two pointers is well-defined, even if either of them
happens to be an object reference. Indeed, constructs like "(void*)3" are also
a C thing (any int can be cast to a pointer, provided the pointer size is at
least as big as the int size on the architecture being compiled for).
The original solution rested on a matter of *uniqueness* of pointers to string
literals. The point was that the characters making up the string were never
intended to be compared, only the pointers themselves, relying on the
uniqueness of pointers to different string values. It’s an extremely delicate
(that is, nerdy) distinction, but it’s clearer when you consider that a pointer
comparison can always be assumed to be really, really cheap (1 machine
instruction, almost always), whereas a string comparison can be quite
expensive, quite apart from the question of whether objects or dynamism are
Another way of saying it is that the original solution leveraged the difference
between literal string values without actually comparing them. That’s why it
was clever (if only it wasn’t fatally flawed for a different reason).
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