Xcode Update Gives Objective-C Garbage Collection

William Henderson writes "That's right, if you haven't read it for yourself yet, Objective-C '2.0' now supports garbage collection. I foresee a great, huge, gigantic debate about to ensue, and a lot of java-heads sparking 'I told you so'. Why not start it here on slashdot?"

Comments

In response to the naysayers...

[Hootenanny]

AFAIK, garbage collection may be enabled or disabled as a compiler option. If you don't like it, then just disable it and carry on.

Not sure if you're joking, but...

[Space cowboy]

An autorelease pool is a promise that when the pool is released, any objects with a retain-count of 1 will be released. So, you create your objects and call the autorelease method on them:

          NSAutoreleasePool *pool = [NSAutoreleasePool new];
          NSObject *myObject = [[NSobject new] autorelease];

All that happens is that the object is added to an internal array, and when the pool itself is released, it calls [release] on all the objects in the array. I guess it actually calls [release] on the object as soon as it's gone into the array as well, or the object's retain count would be 2 when the pool was released (one for the 'new', one for the insert-into-array). So,

        [pool release] ... clears up after you, but it's no garbage collection, it's just a convenient way of using retain/release.

ObjC 2.0 does real garbage collection, like java's. No retain, no release - just automatic management when objects fall out of context.

Simon

Oh dear, where to start ?

[Space cowboy]

• Because it can be a lot slower than C++.
  Well, actually if you really *need* speed, then ObjC groks C perfectly - it's a cast-iron guarantee that any legal C will work in objC, unlike C++. C performance is just as good as C++...
  
  
• C++ gives you control over the object messasing system whereas Objective-C uses virtual methods for pretty much everything and there is nothing you can do about it.
  Um, no. Objective C uses dynamic despatch (ie: the method to run is determined at runtime not compile-time. This is one of its most powerful features. As for "nothing you can do", you can retrieve the bound method as an IMP (like a function pointer) and call it directly to remove any overhead. Useful in loops.
  
  
• Objective-C is actually a lot like COM which is Microsoft's object extension for C. It was designed about the same time with many of the same goals. Both basically came about because of the incredibly slow progress C++ was making at the time.
  No. Objective C was designed as an adaption of the ideas behind smalltalk, as applied to C. It was designed in the early 1980's, COM was designed in 1993, although it wasn't called COM until 1997.
  
  
• Objective-C has no template system. This is a huge advantage for C++.
  Well, that's a matter of opinion, but in any case, Objective C is a dynamic language. Most of the power of templates is encapsulated within the dynamic-despatch abilities of the language, coupled with the 'protocol' feature of the language.
  
  It could be said that Objective-C is a lot like Java with many of the same problems but because it was never marketed with a cross-platform VM it didn't take off like Java.
  I think it is significantly like java, but it's compiled (like C/C++). It's a *lot* faster than Java, and handily beats gcj too, at least on the tests I've done. You need to enumerate these "same problems" before I can respond though.
  
  
• Overall C++ is more C-like than Objective-C. That is it gives you much more control over the exact level of performance versus ease-of-use that you want
  Um, take any legal C code and it *might* compile in C++. It *will* compile in ObjC - how can C++ be "more like C" than ObjC ?
  

ObjC has introspection, dynamic binding, (now) optional garbage collection, (always) a very easy retain-count allocation system, really easy-to-learn constructs (I think there's 12 new statements, or something like that), *and* a weird syntax - it grows on you though :-) It actually does surprise me that more people don't like it. If Macs get more popular, who knows, perhaps it will have its day in the sun...

You need to read the PDF manual. There's a lot of stuff you're saying as fact, that is simply wrong.

Simon

Re:NOOOOOOO #@$#$@

[bar-agent]

Objective C has one of the most elegant reference counting implementations on the planet. Virtually no thinking at all is required to manage memory.

Oh, is that why the Cocoa-Dev mailing list has a brand-new reference counting question every damn day? It is clearly not as simple as you think.

ObjC Referencing Counting In A Nutshell

[Anonymous Coward]

The entire scheme is lexical. If you do a [obj retain] you are responsible for doing the [obj release]. So,

[[NSMutableArray alloc] init]

will require you to release the array object, but

[NSMutableArray array]

won't. Objects added to autorelease pools are automatically released at the end of each runloop. It's a convenience thing... so instead of doing:

NSMutableArray *ary = [[NSMutableArray alloc] init];
[someObject setValue:ary forKey:@"someKey"];
[ary release];

you can do either [[[NSMutableArray alloc] init] autorelease] or [NSMutableArray array] (which does exactly the same thing) and drop the release. Voila! One whole line of code saved/invested. Also you can use ObjectAlloc (from a menu in Xcode) to see stacks of everything that has been allocated.

Having said all of that, memory management is tricky in Cocoa because *everything* is tricky in Cocoa. Lots of entry/exit points in the code which can make it difficult to determine where a problem occurs even w/ NSZombie's and a nice stack trace. Complicated user paradigms, i.e. cut & paste and undo & redo.

That's not a complaint, just a statement. More options = better.