Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS Using the garbage collector
- Thread starter Samppaa
- Start date
- Sort by reaction score
Why are you worried about being considered "noobish"? What do you have to prove to anyone? Unless this is a code sample for a job or university interview, don't worry about this. Even if it is, you have an argument to present.
What languages have you worked in so far? What is the memory management model there? Why do you want to do the same or do something different now?
Have you spent any time with retain/release? It's not *that* much to arse with.
Do you know the compromise you're making in terms of an amortized performance hit at an unknowable schedule? Is this acceptable for your app? (this probably isn't that serious, but the GC is an unknown beast)
are you sure you never want to move this code to the iPad or iPhone? They don't support GC.
Just some things to consider. If you want to use it, go ahead. Worst case you change your mind and rewrite some things.
-Lee
What languages have you worked in so far? What is the memory management model there? Why do you want to do the same or do something different now?
Have you spent any time with retain/release? It's not *that* much to arse with.
Do you know the compromise you're making in terms of an amortized performance hit at an unknowable schedule? Is this acceptable for your app? (this probably isn't that serious, but the GC is an unknown beast)
are you sure you never want to move this code to the iPad or iPhone? They don't support GC.
Just some things to consider. If you want to use it, go ahead. Worst case you change your mind and rewrite some things.
-Lee
Unfortunately C++' memory management (RAII) is different enough from both retain/release and GC that you're just going to have to think about memory management a bit differently. If you're most comfortable letting the GC do the heavy lifting the first time around, have at it. There are definitely some gotchas that may... get you if you aren't careful with your references, allocating a lot of objects in a tight loop, etc. I guess I'd just say give it a try to get your feet wet, and revisit retain/release later if you want to/need it.
-Lee
EDIT: As to when you should retain... you should read this:
http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html
You retain when you want ownership of an object. This means the object will not go away until you either explicitly release it, or relinquish ownership with autorelease, and an autorelease pool is drained. Some objects you will own immediately (alloc, new, copy methods) so you do not need to explicitly retain them. If you have any interest in retain/release, read the memory management guide above.
-Lee
EDIT: As to when you should retain... you should read this:
http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html
You retain when you want ownership of an object. This means the object will not go away until you either explicitly release it, or relinquish ownership with autorelease, and an autorelease pool is drained. Some objects you will own immediately (alloc, new, copy methods) so you do not need to explicitly retain them. If you have any interest in retain/release, read the memory management guide above.
Memory management for Objective-C objects only. C malloc and C++ new are not garbage collected, nor are Core Foundation objects. What you have to do though is set any pointers to garbage collected objects to null when you don't want the object anymore. Best to start reading here:
http://developer.apple.com/mac/libr...onceptual/GarbageCollection/Introduction.html
Having a garbage collector doesn't mean you don't need to think about memory management. It just makes it somewhat harder to get wrong. Understanding what the collector does and (roughly) how it does it is worthwhile and will save you pain when you hit edge cases like resurrection, weak references, CFRetain()'d values, etc...
This is just a personal opinion, but I don't think people should use the GC because they haven't groked retain/releases. IMO, anyone writing Cocoa apps should have this knowledge and then make the deliberate choice to go with the GC if it makes sense in their situation.
gnasher, you made a mistake. If you enable Garbage Collection at the project level to required, then all Core Foundation objects are allocated by the Garbage Collector, so it knows how to release them.
The magic part is, you don't have to do anything special to take advantage of this behaviour, it comes out of the box.
I used to have the opinion, the same as gorillapaws that not knowing how retain/release worked is not good when learning Objective-C and having to rely of the Garbage Collector was a bad idea.
I grew up. Using the Garbage Collector is a revelation. No more stupid, almost impossible to track down memory leaks.
Though, since the iPhone and its ilk still do not have GC, then learning retain/release is still a valuable skill.
The magic part is, you don't have to do anything special to take advantage of this behaviour, it comes out of the box.
I used to have the opinion, the same as gorillapaws that not knowing how retain/release worked is not good when learning Objective-C and having to rely of the Garbage Collector was a bad idea.
I grew up. Using the Garbage Collector is a revelation. No more stupid, almost impossible to track down memory leaks.
Though, since the iPhone and its ilk still do not have GC, then learning retain/release is still a valuable skill.
Until you do something like make a static weak-to-strong NSMapTable and accidentally reference a key somewhere along the reference chain from its associated value.
(that shouldn't leak, but does. Hopefully it'll get fixed)
Of course. Nothing is free. See disadvantages here:
http://developer.apple.com/mac/libr...ption.html#//apple_ref/doc/uid/TP40002457-SW1
-Lee
Note that the performance impact can be in either direction. In particular, in heavily concurrent situations, the global lock taken by -retain/-release on non-CFTypes can be contended.
In general though, yeah, it's a little slower.
<edit>
Doh. Just scrolled down on the document lee1210 linked, and it mentions this case.
</edit>
In general though, yeah, it's a little slower.
<edit>
Doh. Just scrolled down on the document lee1210 linked, and it mentions this case.
</edit>
Yes.
The Documentation said:
But why would you? Take your pick, reference counting or garbage collection. Read the docs. Then read them a couple more times. Then decide which way to go. (I have a long-standing habit of writing to 10.4, begun when the universal SDK was for 10.4, so I have little or no experience with GC.)
Here is one way to simplify your code: use @property/@synthesize for your ivars. If the ivar is set to (retain), you do not have to worry about it, except in your -dealloc method. Use a lot of convenience methods and -autorelease for your temporary objects. That should take care of most or all of your memory management issues.
Ask this question a different way. There are some ambiguities due to English that I can't resolve, and in the ways I resolve them I am still not sure what you're asking.
-Lee
Sorry I was meant to put the code in.. So am I doing the memory management right in this code?
Code:
//
// CountController.m
// StringCounter
//
// Created by Samuli Lehtonen on 1.6.2010.
// Copyright 2010 Test. All rights reserved.
//
#import "CountController.h"
@implementation CountController
-(IBAction)countString:(id)sender
{
NSString * textViewString = [[NSString alloc] init];
textViewString = [textView stringValue];
NSString * string = [[NSString alloc] initWithFormat:@"'%@' has %d characters.",textViewString,[textViewString length] ];
[textViewString release];
[labelView setStringValue:string];
[string release];
}
@endNo, you aren't.
The first thing you do is get a brand new NSString that you own, but don't actually init it to anything of value. NSString is immutable, so you have a pointer to an Object that is basically useless (but you do own it). The very next line, you assign a new Object pointer to this variable (which you don't own) losing the pointer to the empty NSString you do own (which means you'll never be able to release it). You then set "string" to a pointer to an NSString you own (this is fine). You then send release to the return of stringValue, which you don't own. This is a no-no. You then set the string value of labelView to "string", which is fine. You then send release to "string", which you own, so this is correct (you've relinquished ownership, so your responsibilities are fulfilled).
To make this right:
Just set textViewString to [textView stringValue] when you declare it, rather than to a pointer to a new NSString.
Don't send release to textViewString.
-Lee
What is the method name that you got the Object pointer you assigned to textViewString from? Does it contain new, alloc or copy? If so, you own the object and need to release or autorelease. If not, you didn't increment the retain count when you got it, so it's something else's responsibility to deal with it. Also, you aren't releasing textViewString, you're passing release to the Object that textViewString points to. This may seem subtle and splitting hairs, but it's important to understand, IMO.
-Lee
Ok I think I got it, but if I init a string with something I have to use alloc like this?
So I can't do like this?
Thanks for answering my questions! When I clear things I advance in my book again.
Code:
NSString * string = [[NSString alloc] initWithFormat:@"'%@' has %d characters.",textViewString,[textViewString length] ];So I can't do like this?
Code:
NSString * string = [NSString initWithFormat:@"'%@' has %d characters.",textViewString,[textViewString length] ];Thanks for answering my questions! When I clear things I advance in my book again.