Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

ZVH

macrumors 6502
Original poster
Apr 14, 2012
381
51
I've heard it wasn't, yet others seem to swear by it.

One guy told me GC would prematurely mark and collect on class variables without warning. I haven't been able to confirm or deny it. He was referring to this type of allocation:

[NSString stringWithFormat:mad:"%@", @"This is a test"];

versus

[[NSString alloc] initWithFormat: @"%@", @"This is a test"];

He told me the first example could be prematurely collected, as in before it even gets used, whereas the GC would handle the second example properly.

I'm considering switching to a GC environment for development, but not if it's buggy.

Comments anyone?
 
You may wish to forget Garbage Collection and, depending upon your platform requirements, use Automatic Reference Counting instead.

<http://clang.llvm.org/docs/AutomaticReferenceCounting.html>
 
The only odd thing mentioned that I could find was from the Garbage Collection Programming Guide. Under disadvantages it says, "A common design pattern whereby resources are tied to the lifetime of objects does not work effectively under GC". I'd like a better explanation than that.

There are three memory management techniques; manual memory management where you handle the retains and releases, garbage collection (GC) where the runtime takes care of releases, and the new automatic reference counting (ARC) where the compiler balances the retains and releases.

CG and ARC should not be prematurely releasing objects.

In your sample lines, you need to understand that the first does not return a retained object. The life of that object is guaranteed to last to the end of the method it is in. In the second line, the alloc causes a retain. If you assigned the returned value (an object id) of the first line to an instance variable, you'll need to add your own retain to keep it around longer than the call to the method. If you don't do that, the object will disappear upon the next cycle of releasing the memory associated with it. The second line will require a release by you under manual memory management, or the garbage collection will do it if you are using that.

The GC method wasn't a big hit with developers from what I could tell and does not work with iOS. The new ARC method is what developers are moving to, usually away from the manual method.
 
Last edited:
I would strongly discourage moving to garbage collection. The fact that iCloud isn't supported in garbage collected applications should raise questions about its future. From the programming guide:

Not all frameworks and technologies support garbage collection; for example, iCloud is not supported in applications that use garbage collection.

Also: https://news.ycombinator.com/item?id=3603218.
 
I've heard it wasn't, yet others seem to swear by it.

One guy told me GC would prematurely mark and collect on class variables without warning. I haven't been able to confirm or deny it. He was referring to this type of allocation:

[NSString stringWithFormat:mad:"%@", @"This is a test"];

versus

[[NSString alloc] initWithFormat: @"%@", @"This is a test"];

He told me the first example could be prematurely collected, as in before it even gets used, whereas the GC would handle the second example properly.

I'm considering switching to a GC environment for development, but not if it's buggy.

Comments anyone?

So, first off, what everyone else said: don't use GC. ARC killed it. Seriously, don't use it.

That said, what he's probably talking about is things like this:

void *bytes = [someNSData bytes];
[self doSomethingWithSomeBytes:bytes];

Because 'someNSData' is not referenced after the first line, if that's the only live reference to it, it may be collected... *even though* bytes is a pointer to inside of it. This isn't a bug per-se, it's just an unfortunate side effect of having raw pointers in a GC'd language.

You can avoid this by doing something like:

void *bytes = [someNSData bytes];
[self doSomethingWithSomeBytes:bytes];
[someNSData self]; //use someNSData again to keep it live
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.