Re: Is this a bug, or am I hacking?
Re: Is this a bug, or am I hacking?
- Subject: Re: Is this a bug, or am I hacking?
- From: Graham Cox <email@hidden>
- Date: Fri, 15 Aug 2008 10:45:34 +1000
On 15 Aug 2008, at 5:21 am, Allison Newman wrote:
Hi Graham,
Generally speaking, string constants are only optimised within
statically linked binaries. Dynamically linked libraries, such as
dll's, so's and Mac bundles will not share constants.
Basically, under the hood, when you link together all of your object
files at build time, the linker eliminates duplicate constants to
save on memory. Obviously, with dynamically linked code, you cannot
know at link time whether or not a constant is going to be
duplicated in another code module that will be linked at runtime, so
the constant has to be included in the binary. And as it has to be
included in the binary anyhow, there is no benefit to be had in
removing it at runtime, and forcing all of the addresses in the
binary to be recalculated.
Net result, the same constant will be duplicated in two different
binary files that are linked dynamically, and hence pointers to
those constants will have different values in the two different
binaries.
Thanks, I understand this. That's why NSNotificationCenter apparently
comparing the notification name by address seems incorrect - identical
strings could come from anywhere so such a comparison would lead to
bugs (like mine).
That said, Keary's test example would seem to contradict my guess
about what's happening. In my case I simply have:
NSString* kMyConstant1 = @"some_string";
and
NSString* kMyConstant2 = @"some_string";
where one of these is declared in a linked framework, the other is
linked locally.
Doing:
extern NSString* kMyConstant1;
extern NSString* kMyConstant2;
[[NSNotificationCenter defaultCenter] addObserver:self selector:
(<...>) name:kMyConstant1 object:<theObjectOfInterest>];
My observer doesn't receive notifications from kMyConstant2 even
though it's defined to be the same literal string as kMyConstant1.
As it turns out I can get the functionality I need by simply
subscribing to both notifications, but I was trying to avoid linking
in the headers for all the object types that are contained by my data
management code - the UI for that model doesn't otherwise "need to
know" what object types they are, as apart from this one notification,
they conform to a common protocol.
So this isn't in any way a showstopper - but I'd like to understand
the nature of this behaviour so that a) I can avoid it again in future
and b) file a bug if it is one.
cheers, Graham
_______________________________________________
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