2

Possible Duplicate:
NSString retainCount is 2147483647

Let say i have an class named as MyTestClass.h.

There are three NSString variables which are initialized different ways

Class structure is look like

@interface MyTestClass : NSObject {

  NSString *testString1;
  NSString *testString2;
  NSString *testString3;

}

@property (nonatomic, retain) NSString *testString1;
@property (nonatomic, retain) NSString *testString2;
@property (nonatomic, retain) NSString *testString3;

@end

MyTestClass.m

@implementation MyTestClass

@synthesize testString1, testString2, testString3;


-(id) init{

    self.testString1 = @"";

    [self setTestString2:@""];

    testString3 = @"";

}

Now i am planning to create an object of MyTestClass

MyTestClass *obj = [[MyTestClass alloc] init];

I think after this code line execution testString1, testString2 and testString3 retainCounts will be 1.

Am i correct my friends?

may i know that what will happened if i release testString3 ?

Any help on this is appreciated.

Thanks

Community
  • 1
  • 1
Shamsudheen TK
  • 30,739
  • 9
  • 69
  • 102
  • 2
    It is not good to rely on retainCount. We can never be sure how many times framework has retained the object. You read this ->http://www.friday.com/bbum/2011/12/18/retaincount-is-useless/ awesome article by bbum. Basically it is bad to rely on them for memory management. – iNoob Jul 05 '12 at 12:56
  • I linked to the above question as a duplicate, because it also links to the tree of many other related questions on this exact topic, as well as the odd result you'll see in this circumstance (2147483647). It seems that everyone has to experience the weirdness around NSString's retainCount at least once before they realize how useless retainCount is (and why it's a good thing that ARC turns it into a compiler error). – Brad Larson Jul 05 '12 at 15:44

1 Answers1

2

Since you are using literal strings in this example retainCount is of no importance (not even as a delta) since those string objects aren't actually ever going to be dealloc'd.

However, if you were assigning a runtime allocated string to each of your properties, the first two would be retained, the third would not. Since your properties are declared as retain and you're using dot syntax in one and the "setProperty" syntax in the other, the same setter is executed and the object passed to that setter is retained. The third example you're simply setting the backing ivar for the property to the value on the right and not affecting it's ownership.

It's worth noting, retainCount is only ever useful as a delta and shouldn't be thought of as an explicit number. You should never explicitly check the value of retainCount, since it's absolute value is unpredictable and of no use. You seem to understand this in your question, but it's worth restating whenever dealing with retainCount to make sure all involved understand it.

Paul Tiarks
  • 1,881
  • 1
  • 13
  • 10
  • thanks for the quick reply, however may i know that what will happened if i release testString3.I found no crashes!!! could you please explain the behind concept. – Shamsudheen TK Jul 05 '12 at 13:05
  • 1
    Since that object isn't allocated on the heap, it doesn't actually have any ownership. Strings statically declared like that are of a concrete sub-class of the NSString class cluster which render actions like calling release on it moot. It may be best to not use those types of strings in your example, since they are a special case and instead use strings declared with `stringWithFormat:` or another convenience constructor. Also, since you're talking about memory management, I assume you're not using ARC. – Paul Tiarks Jul 05 '12 at 13:09
  • yeah. we are not using ARC and let you know i am a newbie :). Could you please clarify one point. what happened if i call self.testString1 = @"hai"; twice? i think it will leak memory.The first retained string will not be released. Is i need to override the "setTestString1" method and make release call before setting the string second time? – Shamsudheen TK Jul 05 '12 at 13:20
  • No. The purpose of synthesizing properties is so that you don't have to write setters and getters. You simply supply options `(nonatomic, retain)` that you'd like the property synthesized with and the compiler generates a setter that follows these options. This only works if you're going through the setter by using `self.someProperty` syntax or `[self setSomeProperty:aThing]` syntax. Directly assigning to the instance variable backing the property will do nothing as far as retaining/releasing/ownership is concerned. – Paul Tiarks Jul 05 '12 at 13:51