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

Here's my contribution to the debate.

[mccalli]

Fantastic.

I really do feel that manual memory management in most apps is now redundant. i fully accept its need in some cases an indeed I've advocated 'regressing' an app at work, which was ported from C to Java, back into C again to use manual memory management for performance. But that app's an exception - sub-millisecond performance is required. How many day to day apps need that?

I can feel myself waiting a few months, then ordering an updated Objective C coding book to pick this language up now.

Cheers,
Ian

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.

And Leopard has DTrace

[SuperKendall]

Far more exciting is that Leopard gets DTrace. Look at the last line of the page the story links to.

Well, let's say as exciting.

Re:uh, neat....

[jfengel]

It isn't even a question of how good a programmer you are. It's a question of how good a programmer everybody on the team is. And "team" includes every library you use.

When memory is passed across the boundary from one developer to another, you need some kind of mechanism to track who is going to free that memory, and under what circumstances.

Garbage-collected languages make that contract fairly clear. (But not infinitely clear; there are still ways to accidentally pin objects in memory even in a GC language).

In C we got used to putting in comments saying, "I'm passing you back a static structure, so I'm not re-entrant" or "This thing is malloc'ed so free it when you're done" or "You have to pass in a reference to that object and I'll fill it in". As long as discipline is followed the program works brilliantly (no GC overhead) but if any developer anywhere on the project misreads any single one of those comments, you're completely and totally doomed.

There is still software to be cranked out by one guy who can keep the entire thing in his head, but software requirements for most things are too big for just one guy. Even the uberest of uber-hackers is limited by the dumbest guy on his team, especialyl when that dumbest guy (even if he's pretty damn smart) nulls out a memory location that wasn't finished yet.

Re:NOOOOOOO #@$#$@

[m874t232]

You're missing the point of garbage collection. Garbage collection isn't there to save your effort. In fact, garbage collection does not save you effort at all. The purpose of garbage collection is to make the language safe and isolate errors, something that no other storage management scheme can achieve.

Both manual storage management and garbage collection each require a lot of experience to use correctly. Your problem is likely that you underestimate both how much work it took to become proficient at manual storage management/reference counting, and how much work it would take you to become proficient in a garbage collected environment.

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:Why not Objective C?

[Novajo]

Objective-C has no template system. This is a huge advantage for C++.

This is interesting because C++ has templates only because it needs them and Objective-C doesn't have them because there is no need. For instance, you can't have a C++ array of "anything", unless all objects descend from the same class, and then you are restricted to functions that were declared in that base class. That's because C++ is statically typed and needs to know the virtual table to use for the function call (whatever the function is). On the other hand, Objective-C does not need templates because function calls are not looked up through a virtual table, they are dynamically sent as messages, which are handled if the object implements that function. Hence, you can (and do) have a general-purpose array in Objective-C. You can even have a general purpose hash table with changing element types...! I'd love to see an implementation in C++ that is readable.

The "Object Penalty" (i.e. the cost of using a certain object-oriented language) is fixed, and it therefore reduces over time with faster and faster computers. C++ will do anything to make that cost as small as possible, including getting in your way. So really, the advantages of C++ are decreasing over time if you consider all the hoops you have to jump through to get what you want. When you really need performance in Objective-C, you write that little snippet of code in straight C (just like everyone else does in C++ .)

I was a C++ junkie for 10 years until I tried Objective-C and quickly noticed how much more complex a task I could handle without the language getting in my way. You should try it.

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.