Like any object that you want to “stick around” you need to call retain to bump the reference count. The code bumps the reference count for the incoming object, releases the old object and then assigns the instance variable to the new object.

John

-(void) setStr:(NSString *)input
{
[input retain]; // Why ????
[str release];
str = input;
}

What is the purpose of: [input retain]; line for? And there is no release after all.
I thing I do not understand some basic thing here.

I would greately appreciate help with understanding it.

The code example shown is how most all iPhone projects are setup inside the main method, where a pool is allocated and freed.

If you look at the documentation for NSAutoreleasePool, drain states this:

In a reference-counted environment, releases and pops the receiver; in a garbage-collected environment, triggers garbage collection if the memory allocated since the last collection is greater than the current threshold.

In a reference-counted environment, this method behaves the same as release.

If you look at the documentation for release, it states this:

Special Considerations
You should typically use drain instead of release.

When an instance variable is set to nil using this approach [self setStr:nil], the setter retains nil (effectively doing nothing), and as expected, releases the old value. Although somewhat confusing in syntax, this is a reasonable thing to do as the variable will now point to nil, not some random location in memory and the memory is freed.

If you just called str = nil, you would have a memory leak as the variable is being set to nil, however it is not being released.

Hope that helps.

int main(int argc, const char * argv[])
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
.
.
.
[pool drain];
return 0;
}

Within the context of main() there are no objects that are being sent autorelease messages so creating a pool and destroying it is benign – it adds no value, it does no harm. For an introductory tutorial this could cause more confusion with newbies like myself – best to leave it out.

Also, use of:

[pool drain]

implies that this application exists within a garbage collected environment and hence all chatter about memory management is irrelevant. If the application is not running in a GC environment the the correct code is:

[pool release]

The sequence of events that is going on here is:

int main(int argc, const char * argv[])
{
.
.
.
TestClass *ptr = [[TestClass alloc] init];
.
.
.

}

First event above is that an instance of TestClass is created; ‘ptr’ now references that object.

int main(int argc, const char * argv[])
{
.
.
.
TestClass *ptr = [[TestClass alloc] init];
[ptr setStr:@"Fubar"];
.
.
.
}

Next, the instance variable of ‘ptr’ (called ’str’ from above) is now set to reference an NSString object with the value “Fubar”.

int main(int argc, const char * argv[])
{
.
.
.
TestClass *ptr = [[TestClass alloc] init];
[ptr setStr:@"Fubar"];

[ptr release];
.
.
.
}

Next, the destruction of the instance of TestClass as referenced by ‘ptr’ begins. In the process of destroying ‘ptr’, the dealloc method of ‘ptr’ is called which, from above is:

-(void) dealloc
{
[str release];
[super dealloc];
}

The dealloc method releases the instance variable ’str’ then calls [super dealloc] and the object no longer exists. At this point, it is not possible for any part of the class implementation (for this instance) to execute the code:

if (str)
do something…
else
do something else…

because the object no longer exists. In face the only point that I see there is a threat is is you inserted some code between:

[str release]

and

[super dealloc]

Yes, after [str release] is called but before [super dealloc] is called the condition where ’str’ points to a memory location which has already been deallocated is true. But since no one would do this the threat is zero. Am I not correct? What am I missing? Note that this is what the test code is doing: inspecting the value of ’str’ after deallocating the memory to which it refers but before [super dealloc] is called.

Looking at this a little deeper, if indeed the TestClass dealloc method was replaced with:

-(void) dealloc
{
[self setStr:nil];
[super dealloc];
}

You now have a memory leak, yes? The actual memory space allocated to hold the NSString ’str’ has not been released. All that has happened is that the reference to the NSString object has been wiped clean but NSString ’str’ still exists in all its glory.

One further question, within the context of main(), the ’str’ instance variable of TestClass has been set to “Foobar” as follows:

int main(int argc, const char * argv[])
{
.
.
.
TestClass *ptr = [[TestClass alloc] init];
[ptr setStr:@"Fubar"];
.
.
.
}

I assume, and please correct me if wrong, that this code snippet does NOT cause and instance of NSString with a reference count of 1 to be created within the context of main(), prior to the code inside setStr:(NSString *)s being executed. If this is not true then there is another memory leak since setStr:(NSString *)s retains the object which would bump its reference count to 2 and there is only one counteracting release in the lifecycle – the one in the dealloc method

I was referring to a developer inadvertently referring to ’str’ after the variable has been released. If the variable is not set to nil, somewhere else in the code you could check the variable to see if it is nil as a means to know if it’s been deallocated, which could result in an attempt to access a variable that has been released.

The dealloc method won’t be execute only in the end? How at some point inside the class an attempt was made to check th ’str’ AFTER dealloc? Is it possible?? I’m new in MAC programming..

superb…..

Keep it up!!!!

Sorry for the delayed response!

What I don’t understand though is… isn’t dealloc only run on an object when it is being removed from memory (ie, at the end of its life)? If the object in this example has itself been removed from memory, how would it be at all possible to access its str property?

Kenneth