I just noticed an earlier message in this thread that points out that
stringWithString: does in fact do the same optimization as -copy for
constant strings. So the approach in Apple's sample code does not
protect from the bundle unloading problem. Aside from the
OTHER_CFLAGS approach Jesper describes, the only solution I can think
of is to use [NSMutableString stringWithString:] instead of [NSString
stringWithString:].
But of course this is an odd case, and the vast majority of the time
it's just wasted code to say stringWithString:@"abc".
--Andy
On May 27, 2009, at 7:11 PM, Jesper Storm Bache wrote:
Assuming that NSString may be using CFStrings, then the issue may be
related to const strings.
See information regarding "OTHER_CFLAGS = -fno-constant-cfstrings"
The basic issue is that when constant cfstrings is enabled, then the
string may be put into the TEXT segment and you end up passing a
pointer to that TEXT segment around. When the bundle/plug-in unloads
the segment is removed from the mapped memory and you'll get a crash
if you try to use it.
Therefore, unloadable plug-ins (that use cfstrings) should use fno-
constant-cfstrings.
Jesper Storm Bache
On May 27, 2009, at 3:42 PM, Andy Lee wrote:
On Wednesday, May 27, 2009, at 11:48AM, "Michael Ash" <michael....@gmail.com
> wrote:
This may seem nitpicky but I see a lot of newbies writing code just
like this. Their code is filled with stringWithString: calls for
absolutely no purpose, so I want to discourage that sort of thing.
Just for grins, I searched for calls to stringWithString: in the
Apple examples and came across a puzzling comment in /Developer/
Examples/CoreAudio/AudioUnits/SampleAUs/CocoaUI/
SampleEffectCocoaViewFactory.m:
- (NSString *) description {
// don't return a hard coded string (e.g.: @"Sample Effect Cocoa
UI") because that string may be destroyed (NOT released)
// when this factory class is released.
return [NSString stringWithString:@"Sample Effect Cocoa View"];
}
It looks like an Audio Unit is some kind of pluggable module? So
maybe if an NSString constant had been used it would get unloaded
when the module is unloaded -- hence the stringWithString:?
I noticed the doc for stringWithString: says that it copies the
string's characters, so in theory it's guaranteed to create a new
instance, unlike copy which will return the self-same instance when
the receiver is immutable. On the other hand, the doc for
copyWithZone: says it returns a new instance, which it doesn't
necessarily. I'll file a documentation Radar about this later --
the vast majority of the time it's an implementation detail we
shouldn't care about, but there are times it's useful to know when
a copy is not a copy.
--Andy
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/jsbache%40adobe.com
This email sent to jsba...@adobe.com
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
