Basically, the question is - are the following essentially the same?
NSString *value1 = ...;
NSString *value2 = [[NSString alloc] initWithString:value1];
and
NSString *value1 = ...;
NSString *value2 = [value1 copy];
Conceptually, yes. However, there is one difference: alloc always creates a new string, whereas copy may return the same string.
In particular, immutable objects, such as immutable strings, are likely respond to copy by returning themselves rather than creating and returning a copy. (After all, if you can't change anything about the original, why would you really need a copy?) Mutable strings will respond to it by creating and returning a copy, as you'd expect.
initWithString: is in the middle: It may release the receiver and return the string you gave it, similar to how copy may return the receiver. However, if that happens, it means you wasted the creation of the string you created with alloc. With copy, you may not need to create any additional objects at all.
About the only reason to use alloc and initWithString: is if you have your own subclass of NSString and want to make an instance of it from an existing string. copy won't use your desired subclass. Since subclassing NSString is practically never warranted in Cocoa, the same is true of using initWithString: (or stringWithString:).
So the bottom line is, just use copy (or mutableCopy). It's shorter, clearer about your intent, and can be faster.
Non-mutable strings are treated a bit special, compared to ordinary objects, so in this case, yes, the two operations are the same.
To wit:
NSString *str1 = #"string";
NSString *str2 = [str1 copy];
NSString *str3 = [[NSString alloc] initWithString: str1];
NSLog(#"str1: %p, str2: %p, str3: %p", str1, str2, str3);
Which gives me the following output:
str1: 0x108a960b0, str2: 0x108a960b0, str3: 0x108a960b0
Since the pointer addresses are the same, we are talking about the same object.
Related
I have an NSMutableArray i am trying to convert into a string.
Declaring my NSMutableArray...
NSMutableArray *listData;
And later inside a method...
NSString *foo = [listData componentsJoinedByString:#"|"];
NSLog(#"%#",foo);
It seems no matter what i try i keep getting EXC_BAD_ACCESS.
To make sure each element in my array was an NSString i also tried this...
NSMutableArray *mArray = [[NSMutableArray alloc] init];
for (id ln in listData) {
NSString *boo = [NSString stringWithFormat: #"%#",ln];
[mArray addObject:boo];
}
NSString *foo = [mArray componentsJoinedByString:#"|"];
NSLog(#"%#",foo);
I can manipulate my NSMutableArray by adding/deleting objects in the same method or other methods inside my class. But when i try "componentsJoinedByString" the error pops up. Does anyone have any advice or another way i can combine this array into a single NSString?
In the code you've given, there will never be an NSMutableArray for listData. At some point in your code, you'll need to create one, and presumably populate it.
Edit
Okay, so you may get into memory management problems here, so let's be a bit clearer:
You're synthesizing getters and setters for the instance variable, so it's good practice to use those to access it, they'll take care of retain and releasing appropriately.
To set listData you can simply use
self.listData = [listManage getList:[[NSUserDefaults standardUserDefaults] stringForKey:#"list_name"] list:#"LIST"];
or
[self setListData:[listManage getList:[[NSUserDefaults standardUserDefaults] stringForKey:#"list_name"] list:#"LIST"]];
if you prefer.
I have a situation where I need to use some strings temporarily but I've read so many conflicting things that I'm a bit confused as to what the best way to proceed is.
I need to assign some strings inside an if structure but use them outside the if structure so they need to be created outside the if, I was thinking something like:
NSString *arbString = [[NSString alloc] init];
if(whatever)
{
arbString = #"Whatever"
}
else
{
arbString = #"SomethingElse"
}
myLabel.text = arbString;
[arbString release];
I have seen examples where people just used:
NSString *arbString;
to create the string variable
Google's Objective C guide says it's preferred to autorelease at creation time:
"When creating new temporary objects, autorelease them on the same line as you create them rather than a separate release later in the same method":
// AVOID (unless you have a compelling performance reason)
MyController* controller = [[MyController alloc] init];
// ... code here that might return ...
[controller release];
// BETTER
MyController* controller = [[[MyController alloc] init] autorelease];
So I have no idea, which is the best practice?
In the example you posted, you actually lose the reference to the NSString you created when you assign it in arbString = #"Whatever". You then release the string constant (which is unreleasable, by the way).
So there's a memory leak, since you never release the NSString you created.
Remember that all these types are pointers, so = only reassigns them.
As for the question, in this example, you don't need the [[NSString alloc] init]. You don't need to copy the string into a local variable anyway, you can just set myLabel.text to the string constant #"Whatever".
(edit: that's not to say that you can't use your pointer arbString, arbString = #"Whatever"; myLabel.text = arbString is fine. But this is just pointer assignment, not copying)
If you needed to manipulate the string before you returned it, you would create an NSMutableString, and either release or auto-release it. Personally, create autoreleased objects using class methods, so in this example, I'd use [NSString string], or [NSString stringWithString:], which return autoreleased objects.
I have problem with
NSString *filePaht = [[NSBundle mainBundle] pathForResource:(NSString *)name ofType:(NSString *)ext];
if I used
NSString *filePaht = [[NSBundle mainBundle] pathForResource:#"soundName" ofType:#"aiff"];
it's OK. but when I used
NSString *fileName = [[file.list objectAtIndex:index] objectForKey:#"soundName"];
NSString *filePaht = [[NSBundle mainBundle] pathForResource:fileName ofType:#"aiff"];
It's not work
have any idea !?
Thanks
I am going to guess that fileName from file.list includes the file extension. So you are searching for "soundName.aiff.aiff" which does not exist. Try passing #"" for type or stripping the extension from fileName:
fileName = [fileName stringByDeletingPathExtension];
Check your Debugger Console, as it may be telling what you're doing wrong.
[file.list objectAtIndex:index]
If you're getting an NSRangeException, it may be because index contains an index that is outside the bounds of the array. Remember that arrays in Cocoa are serial, not associative; if you remove an object, the indexes of all the objects that came after it will go down by 1, upholding the invariant that 0 ≤ (every valid index) < (count of objects in the array).
It could also be because you never declared a variable named index.
NSString *fileName = [[file.list objectAtIndex:index] objectForKey:#"soundName"];
NSString *filePaht = [[NSBundle mainBundle] pathForResource:fileName ofType:#"aiff"];
If nothing is happening or you get an NSInternalInconsistencyException, it could be one of:
fileList is nil.
The dictionary returned from [file.list objectAtIndex:index] does not have an object for the key soundName.
If you got a “does not respond to selector” message in the Console, it may be one of:
file.list is an object, but not an NSArray.
[file.list objectAtIndex:index] is not an NSDictionary.
fileName ([[file.list objectAtIndex:index] objectForKey:#"soundName"]) is not an NSString.
Remember that the class name you use when you declare the variable doesn't matter except to the compiler; at run time, it's just a variable holding a pointer to an object. The object can be of any class. It is perfectly valid to put something that isn't an NSString into an NSString * variable; it simply carries a very high (near certain) risk of wrong behavior and/or crashing shortly thereafter.
Such a crash will usually manifest in the form of a “does not respond to selector” exception (after something sends the object a message that NSString objects, for example, should respond to, but that the object doesn't respond to because it isn't an NSString).
Whichever problem you're having, you can use the Debugger to investigate.
Sorry with my fault.
I get data from XML file
and that data include "\n". yes I see "\n" so I replace with #""
but it not enough I must trim space value again.
Thanks for all advice ^_^
What is the difference between copy and mutableCopy when used on either an NSArray or an NSMutableArray?
This is my understanding; is it correct?
// ** NSArray **
NSArray *myArray_imu = [NSArray arrayWithObjects:#"abc", #"def", nil];
// No copy, increments retain count, result is immutable
NSArray *myArray_imuCopy = [myArray_imu copy];
// Copys object, result is mutable
NSArray *myArray_imuMuta = [myArray_imu mutableCopy];
// Both must be released later
// ** NSMutableArray **
NSMutableArray *myArray_mut = [NSMutableArray arrayWithObjects:#"A", #"B", nil];
// Copys object, result is immutable
NSMutableArray *myArray_mutCopy = [myArray_mut copy];
// Copys object, result is mutable
NSMutableArray *myArray_mutMuta = [myArray_mut mutableCopy];
// Both must be released later
copy and mutableCopy are defined in different protocols (NSCopying and NSMutableCopying, respectively), and NSArray conforms to both. mutableCopy is defined for NSArray (not just NSMutableArray) and allows you to make a mutable copy of an originally immutable array:
// create an immutable array
NSArray *arr = [NSArray arrayWithObjects: #"one", #"two", #"three", nil ];
// create a mutable copy, and mutate it
NSMutableArray *mut = [arr mutableCopy];
[mut removeObject: #"one"];
Summary:
you can depend on the result of mutableCopy to be mutable, regardless of the original type. In the case of arrays, the result should be an NSMutableArray.
you cannot depend on the result of copy to be mutable! copying an NSMutableArray may return an NSMutableArray, since that's the original class, but copying any arbitrary NSArray instance would not.
Edit: re-read your original code in light of Mark Bessey's answer. When you create a copy of your array, of course you can still modify the original regardless of what you do with the copy. copy vs mutableCopy affects whether the new array is mutable.
Edit 2: Fixed my (false) assumption that NSMutableArray -copy would return an NSMutableArray.
I think you must have misinterpreted how copy and mutableCopy work. In your first example, myArray_COPY is an immutable copy of myArray. Having made the copy, you can manipulate the contents of the original myArray, and not affect the contents of myArray_COPY.
In the second example, you create a mutable copy of myArray, which means that you can modify either copy of the array, without affecting the other.
If I change the first example to try to insert/remove objects from myArray_COPY, it fails, just as you'd expect.
Perhaps thinking about a typical use-case would help. It's often the case that you might write a method that takes an NSArray * parameter, and basically stores it for later use. You could do this this way:
- (void) doStuffLaterWith: (NSArray *) objects {
myObjects=[objects retain];
}
...but then you have the problem that the method can be called with an NSMutableArray as the argument. The code that created the array may manipulate it between when the doStuffLaterWith: method is called, and when you later need to use the value. In a multi-threaded app, the contents of the array could even be changed while you're iterating over it, which can cause some interesting bugs.
If you instead do this:
- (void) doStuffLaterWith: (NSArray *) objects {
myObjects=[objects copy];
}
..then the copy creates a snapshot of the contents of the array at the time the method is called.
The "copy" method returns the object created by implementing NSCopying protocols copyWithZone:
If you send NSString a copy message:
NSString* myString;
NSString* newString = [myString copy];
The return value will be an NSString (not mutable)
The mutableCopy method returns the object created by implementing NSMutableCopying protocol's mutableCopyWithZone:
By sending:
NSString* myString;
NSMutableString* newString = [myString mutableCopy];
The return value WILL be mutable.
In all cases, the object must implement the protocol, signifying it will create the new copy object and return it to you.
In the case of NSArray there is an extra level of complexity regarding shallow and deep copying.
A shallow copy of an NSArray will only copy the references to the objects of the original array and place them into the new array.
The result being that:
NSArray* myArray;
NSMutableArray* anotherArray = [myArray mutableCopy];
[[anotherArray objectAtIndex:0] doSomething];
Will also affect the object at index 0 in the original array.
A deep copy will actually copy the individual objects contained in the array. This done by sending each individual object the "copyWithZone:" message.
NSArray* myArray;
NSMutableArray* anotherArray = [[NSMutableArray alloc] initWithArray:myArray
copyItems:YES];
Edited to remove my wrong assumption about mutable object copying
NSMutableArray* anotherArray = [[NSMutableArray alloc] initWithArray:oldArray
copyItems:YES];
will create anotherArray which is a copy of oldArray to 2 levels deep. If an object of oldArray is an Array. Which is generally the case in most applications.
Well if we need a True Deep Copy we could use,
NSArray* trueDeepCopyArray = [NSKeyedUnarchiver unarchiveObjectWithData:
[NSKeyedArchiver archivedDataWithRootObject: oldArray]];
This would ensure that all levels are actually copied retaining the mutability of the original object at each level.
Robert Clarence D'Almeida,
Bangalore, India.
You're calling addObject and removeObjectAtIndex on the original array, rather than the new copy of it you've made. Calling copy vs mutableCopy only effects the mutability of the new copy of the object, not the original object.
To state it simply,
copy returns an immutable (can't be modified) copy of the array,
mutableCopy returns a mutable (can be modified) copy of the array.
Copy (in both cases) means that you get a new array "populated" with object references to the original array (i.e. the same (original) objects are referenced in the copies.
If you add new objects to the mutableCopy, then they are unique to the mutableCopy. If you remove objects from the mutableCopy, they are removed from the original array.
Think of the copy in both cases, as a snapshot in time of the original array at the time the copy was created.
Assume
NSArray *A = xxx; // A with three NSDictionary objects
NSMutableArray *B = [A mutableCopy];
B's content is NSDictionary object not NSMutableDictionary, is it right?
-(id)copy always returns a immutable one & -(id)mutableCopy always returns a mutable object,that's it.
You have to know the return type of these copying stuff and while declaring the new object which one will be assigned the return value must be of immutable or mutable one, otherwise compiler will show you error.
The object which has been copied can not be modified using the new one,they are totally two different objects now.
I'm working with AsyncSocket where the the AsyncSocket object calls a delegate method below whenever it receives data from remote end:
- (void)onSocket:(AsyncSocket*)socket didReadData:(NSData*)data withTag:(long)tag;
Now, within this method, I pass the NSData object into the following command to get a NSString representation of the data received:
NSString *body = [NSString stringWithCString:[data bytes] length:[data length];
Does NSString stringWithCString: length: retain the byte array I pass in? Do I need to retain the NSData *data? Do I need to be releasing NSString *body at the end?
Thanks. I want to get memory management right in terms of delegates methods...
Does NSString stringWithCString: length: retain the byte array I pass in?
It's not possible to retain a byte array. Only objects can be retained.
Do I need to retain the NSData *data?
No. Because there's no way for the string to retain the data (which it doesn't know about) or its contents, the string will copy the bytes. (Think about what you would do if you were implementing this method: This is it.)
Let's change cases and look at what you would do if you were passing the data object in, instead of the bytes.
If the string does retain the data, then you don't need to worry about the data dying out from under the string, because the string is retaining it. If it doesn't retain it, the string either made its own copy or isn't holding on your data at all.
So other objects' retentions don't matter. Don't worry about them. Worry only about who owns what, and retain or not accordingly.
Do I need to be releasing NSString *body at the end?
Well, you didn't retain it, you didn't alloc it, and you didn't copy it. Therefore, you don't own it. So, no.
If you do want to take ownership of the object, you'd retain it or make (and then own) your own copy. Then you would release it.
Simple answer with proof.
NSString stringWithCString:encoding: copies the byte buffer to make the string. The buffer is up to you to maintain.
Proof:
Code:
const char* hardString = "Hello, World";
char *buffer = nil;
buffer = calloc(13, 1);
bzero(buffer, 13);
memcpy(buffer, hardString, 12);
NSString *aString = [NSString stringWithCString:buffer encoding:NSUTF8StringEncoding];
NSLog(#"aString: %# \t filled buffer:(%p) [%s]", aString, (void*)buffer, buffer);
bzero(buffer, 13);
NSLog(#"aString: %# \t zeroed buffer:(%p) [%s]", aString, (void*)buffer, buffer);
free(buffer);
NSLog(#"aString: %# \t free'd buffer:(%p)", aString, (void*)buffer);
buffer = nil;
NSLog(#"aString: %# \t nulled buffer:(%p)", aString, (void*)buffer);
Result:
aString: Hello, World filled buffer:(0x10010a790) [Hello, World]
aString: Hello, World zeroed buffer:(0x10010a790) []
aString: Hello, World free'd buffer:(0x10010a790)
aString: Hello, World nulled buffer:(0x0)
You don't have to retain the NSData array since its content will be converted/copied into the new NSString object.
The NSString object returned has a retain count of 1 but it has been added to the autorelease pool.
This means that it will be automatically released once the autorelease pool gets destroyed. In case you are using the default autorelease pool created by AppKit this will occur at the end of the current event loop handling. So if you use this string object only in that method "onsocket:..." you are fine.
If you want to keep the NSString object after leaving the method you should retain it or instantiate it by allocating and initializing it like this:
[[NSString alloc] initWithBytes:[...] length:[...] encoding:[...]]
This NSString object will also have a retain count of 1 but you have to explicitly release it when you no longer need it.
Btw. [NSString stringWithCString:length:] is deprecated since OSX 10.4
Pholker is correct; you should be using stringWithCString:encoding: instead.
Retain/Release is only needed for objects; as you are passing in a C-string (which is not an object, unlike NSString) there is nothing to retain or release.
As you are using a convenience constructor the NSString has a retain count of 1 but is added to the autorelease pool, so at some time after you leave the code block, this will be released. You don't need to explicitly use the alloc and init methods to be able to retain it. I mean, it is created with a retain count of 1 (but will be autoreleased) If you call retain on it, that will increment the count to 2, but at some time later, it will be autorelased, and the retain count will drop to 1.
If you don't call init, retain, copy or mutableCopy on an object, you can assume it will be autoreleased and you don't need to explicitly release anything. But if you want to hold onto an object outside of a code block, you need to call retain and then release it some time later (usually in the dealloc method of the class in which the object was created).