4

So, I'm fairly certain that if I plan on manipulating strings often, such as with stringByAppendingString, I should be using variables of type NSMutableString.

But what if I'm doing something like this?

UILabel *someLabel = [[UILabel alloc] init];
[someLabel setText: [[someDictionary objectForKey:@"some_key"] stringByAppendingString:@"some other string"];

I read that if you use stringByAppendingString on an NSString, you end up with leaks because the pointer associated with the initial NSString moves around, pointing to the new string created by the append, whereas with NSMutableString, your pointer always points to that mutable string.

So my question is, what is implicitly happening when I call stringByAppendingString on something that is a string, but not explicitly an NSString or an NSMutableString? Such as, in my above case, the value of some key in a dictionary. Is doing this wrong, and should I be doing something like below?

[[[NSMutableString stringWithString:[someDictionary objectForKey:@"some_key"]] stringByAppendingString:@"some other string"]]
Joseph
  • 207
  • 3
  • 10

4 Answers4

5

I read that if you use stringByAppendingString on an NSString, you end up with leaks because the pointer associated with the initial NSString moves around, pointing to the new string created by the append, whereas with NSMutableString, your pointer always points to that mutable string.

That sounds like the advice of someone who didn't quite have a grasp of what is going on with the memory management. Sure, [NSString stringByAppendingString] returns a new string. But what you do with that new string is up to you. You could certainly cause a memory leak by reassigning the result to a retained property in a careless fashion, like so:

myStringProperty = [myStringProperty stringByAppendingString:@" more bits"];

The correct form would be to use self, like so:

self.myStringProperty = [myStringProperty stringByAppendingString:@" more bits"];

Follow the cocoa memory guidelines.

As for dictionaries and other collection types: treat what comes out of the dictionary appropriately given the type you know it to be. If you pull an object out which is actually an NSString, but try to use it as a NSMutableString, your app will fall over (with 'selector not found' or similar). So in that case, you do need to make a new NSMutableString from the NSString.

Interesting note: Apple chose to make NSMutableString a subclass of NSString. Something about that seems unwise to me -- if something looks to be immutable, because it has type NSString, I want it to be immutable! (But in fact it could be NSMutableString.) Compare that to Java, which has a String class and a completely separate BufferedString class.

occulus
  • 16,959
  • 6
  • 53
  • 76
  • Your comments about NSMutableString are overly critical. If you think of it in terms of an object hierarchy, NSMutableString makes perfect sense, just because it **is** an instance of an NSString, with mutable capabilities. Unless you explicitly need the mutability, defaulting to immutability is appropriate. The String and StringBuffer class are identical because they both implement nearly the same *interfaces*, which is another manner of defining types. Objective-C's implementation is perfectly fine, because the behaviors of both the base and sub class would need the same implementation. – Wayne Hartman Mar 04 '11 at 18:00
  • NSMutableString isn't just a specialization of NSString; it's a specialization which also breaks one of the core promises of NSString. The API for NSString says NSString is immutable. The API saying "Immutable" isn't just them telling you that you can't change the contents; it's also a promise that the contents won't change behind your back. NSMutableString completely breaks that. Two classes having very similar common functionality doesn't actually imply they should be super/sub class related (although it might often be the case), nor does it imply that doing so will always be correct. – occulus Mar 04 '11 at 18:30
  • I think you're still trying to paint the world with Java tinted glasses. The dynamic nature of Objective-C lends itself to being able to change the rules--not just at compile time, but runtime as well. Categories are a perfect example of that. It is a core tenant of the language. While I would have opted for the Java approach to String-like objects in objc, the mutability of objects in Java can be enforced, ala `final`. Being able to change or subclass the `String` object would shake the very foundations of Java, while the dynamic nature of objc is a ***feature*** of the language. – Wayne Hartman Mar 04 '11 at 18:42
  • Or, to turn things on their head: the way things are, you can be passed something of type NSString, and treat it exactly as contracted in the API docs, and yet it is possible for your program to break depending on whether the thing of type NSString was actually an instance of NSMutableString or not. This doesn't seem to break the LSP (http://en.wikipedia.org/wiki/Liskov_substitution_principle) but it's still not correct IMO. The fact that you have to worry about a type actually being a certain subtype is a bad 'OO smell'. – occulus Mar 04 '11 at 18:46
  • @wayne-hartman I have no problem at all with the dynamic native of oC, or the power that gives the programmer. With power also comes responsibility. I've written plenty of categories in my time, for example, but none that negated a contract of the class I'd categorised. If I did such a thing, and then someone else's code broke, I wouldn't blame the author of the other code, I'd blame me. – occulus Mar 04 '11 at 18:58
  • @occulus Please can you tell me in bit detail whats the difference between self.myStringProperty and myStringProperty ... – S.J Jun 10 '13 at 09:36
  • 1
    @S.J self.myStringProperty uses dot notation to access the getter or setter method for that property. If you omit the self. part, you access the class value behind the property directly. If you're using ARC, this is a less crucial difference than it used to be, since ARC handles the memory management that used to be more explicit in the setter method. – occulus Jun 10 '13 at 10:45
3

I've always been a fan of [NSString stringWithFormat@"%@%@", a, b]; because then you clearly get a new autoreleased string and can dispose of "a" and "b" correctly.

With [someDictionary objectForKey:@"some_key"], you will be getting the type of object that was put into that dictionary originally. So blindly calling stringByAppendingString without knowledge of what's in that dictionary seems like a bad idea.

Luke
  • 11,426
  • 43
  • 60
  • 69
Staros
  • 3,232
  • 6
  • 30
  • 41
  • 1
    Ah right, I forgot about this method. I agree, it's pretty straightforward and you always know what to expect. I think that'll be best for me with what I'm trying to do. Thanks! – Joseph Mar 07 '11 at 16:47
3

-stringByAppendingString is going to return you a new NSString that is distinct from both strings involved. In other words:

NSString *string3 = [string1 stringByAppendingString:string2];

string3 is an entirely new string. string1 isn't changed at all, nothing happens to its memory location or contents. The person who told you that probably just misunderstood what was going on.

[mutableString1 appendString:string2];

In this case, mutableString1 still points at the same object, but the contents of that object have been altered to include string2.

One last thing to keep in mind is that if you are using mutable strings, you should be careful with sharing references to it. If you pass your mutable string to some function which keeps a pointer to that mutable string and then your code changes that mutable string at some point in the future, the other reference is pointing at exactly the same object which means the other code will see the change as well. If that's what you want, great, but if not you must be careful.

One way to help avoid this problem is to declare your @property statements for NSStrings to be "copy" instead of "retain". That will make a copy of your mutable string before setting it in your property and the -copy method implicitly gives you a NON-mutable version, so it'll create an NSString copy of your NSMutableString.

Kenny Wyland
  • 20,844
  • 26
  • 117
  • 229
0

If you follow the rules for memory management, you will be fine using stringByAppendingString. In a nutshell:

  1. if you own an object, you need to release or autorelease it at some point.
  2. you own an object if you use an alloc, new, or copy method to create it, or if you retain it.

Make sure you read up on Apple's Memory Management Rules.

In the first code sample in your question, you aren't using alloc, new, copy or retain on any of the NSStrings involved, so you don't need to do anything to release it. If outside of the code that you've included in the sample you are using alloc, new, copy or retain on any NSStrings, you would need to ensure that they are released later.

Greg
  • 33,450
  • 15
  • 93
  • 100