Xcode Update Gives Objective-C Garbage Collection 285
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?"
Here's my contribution to the debate. (Score:5, Insightful)
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
Re:Here's my contribution to the debate. (Score:3, Informative)
Re:Here's my contribution to the debate. (Score:2)
Yeh, let's bring back allocating memory on a big sheet of graph paper on the wall of the coding pen!
Take a look at D if you can (Score:2)
I might consider it, too, if I hadn't discovered the D programming language. I can't do a proper comparison because I discovered D shortly after I started experimenting with Obj-C and lost all interest in the latter and no longer remember much about it except that it belonged to the "fast, not convenient" camp, like C and C++.
D was designed from the ground up as a memory managed Super C. The
Re:Take a look at D if you can (Score:2)
The thing about garbage collection is that 80% of the time you don't need it, but the other 20% of the time not having it can really be a pain in the ass. I think that a lot of it has to do with the fact that, most of the time, memory management is just something that has to be done, and it's the sort of thing that compilers are better at than humans. Sometimes though
Re:Here's my contribution to the debate. (Score:2)
Every app that ever interacts with a user. It is never acceptable for an app to stop-the-world while it does something that I (as a user) do not care about. I get enough spinning beach balls as it is.
Re:Here's my contribution to the debate. (Score:3, Informative)
"Stop the world" garbage collection for this app usually takes less than 13ms. And it very rarely occurs - you can code appropriately for a garbage collector too, and minimise it ever reaching this level. Usual GC times is between There isn't a human alive that could interact with a
Re:Here's my contribution to the debate. (Score:2)
Cheers,
Ian
Re:Here's my contribution to the debate. (Score:2)
"Usually" isn't good enough, not when "usually" just made you drop a video frame or overrun a sound buffer. Out of curiosity, though, what language is this? Experiences I have had with Java involved watching the GUI freeze when garbage collection happens. I would be happy to hear that GC wait times had indeed gotten this fast, though it's also likely that your fast GC is a result of your particular allocation patterns.
Re:Here's my contribution to the debate. (Score:2)
Yes, but not every app a user interacts with has video or sound. And, doesn't the OS run most video and sound processing? Just because your own app is garbage-collected, that does not necessarily have an impact on how the OS does what it does.
Re:Here's my contribution to the debate. (Score:2)
No -- the OS's job is to deliver buffers to and from user space programs. The user space programs perform the processing. If a user space program doesn't deliver or retrieve a buffer in time, you get an buffer underrun or overrun, respectively.
Re:Here's my contribution to the debate. (Score:2)
I'll not much of a Java fan, but in all fairness the last time that I saw a Java based GUI "pause" due to garbage collection was at least 3-4 years ago while IDEA in this case. We're using Eclipse now at work and it doesn't stop and pause for garbage collection. It is slow all the time. ;-) But I don't think I can blame the VM for that on
Re:Here's my contribution to the debate. (Score:2)
You realize that a call to malloc is nondeterministic don't you? You get the same problem with manual memory management, there is just a lower average time; but 'stop the world' still happens.
Re:Here's my contribution to the debate. (Score:2)
malloc only blocks threads that are calling malloc. "Stop the world" blocks threads no matter what they are doing. Big difference.
Re:Here's my contribution to the debate. (Score:2)
Yes, it is. But, the "traditional" memory management in Cocoa is already at least 90% automated. What it amounts to is a few boilerplate calls in accessor methods. Xcode has been able to automatically generate simple accessors for quite some time, and for not-so-simple use there's Accessorizer.
The biggest stumbling block I see most newbies having is that a) they're accustomed to not doing any memory management at all in Java a
Re:Here's my contribution to the debate. (Score:3, Informative)
Bad idea if you're doing heap allocation in a time-critical code section. Heap allocation ala 'malloc' isn't deterministic, it can tak
Technical details needed! (Score:3, Insightful)
What garbage collection technique is used here? How does it differ from the Boehm GC-based technique offered by the GCC Objective-C compiler?
Are any guarantees given with regards to the performance of the collector? Does it suffer from many of the problems that plagued the Java GC?
What sort of modifications do we have to make in order to take advantage of this support?
Specifics please? (Score:2)
I have been a Java developer for eight years. What problems have plagued Java garbage collection?
Re: (Score:3, Insightful)
Re:Specifics please? (Score:2)
Your comments are useful and I agree for the most part. However, I disagree with your assertions that Java proponents claim rapid application development. (And really, I am just nitpicking for argument sake.) Java development has a lot of programmer overhead in that there are many ways to solve the problem and nobody has decided which are the best. With that, you end up having to experiment with a variety of frameworks at every tier of your application. JSF or Tapestry? Hibernate, JDO, or Toplink? EJ
Re:Specifics please? (Score:2)
Exactly. It's like how everybody thinks they're an above-average driver.
Java doesn't guarantee correctness, but it catches more bugs, and it makes some of the more dangerous ones - the buffer overflows, the stack overflows, etc, etc - practically impossible. I'd be curious to know if Objective C does the same thing
Unfortunately no; ObjC is just C with some syntax changes to support OOP. L
Re:Specifics please? (Score:2)
But the real problem with garbage collection in Java is the poor language and library design, which forces applications to generate huge amounts of garbage and leads to a lot of unnecessary memory management overhead. Java, unfortunately, gives garbage collection a bad name.
Re:Specifics please? (Score:2)
Let's start with the admitted fact that the *basic* allocator in the Sun JVM requires on the order of twice the allocated heap space. But the idea is that the unused half will be paged out by the OS even though the perceived memory usage doesn't reflect that. In addition, the same reasoning is applied to the often cited "problem" that the Sun JVM heap never sshrinks.
Not to mention that you can add on to
Re:Specifics please? (Score:2)
It is unfortunate the grandparent post is full of personal remarks, but the points are valid nonetheless. Your comment about Eclipse memory consumption is a bit odd. Just because top says “64M” does not mean that you have that much less physical memory available. Read this: http://en.wikipedia.org/wiki/Virtual_memory [wikipedia.org] Also, Eclipse is a huge application with a lot of useful features built on a very extensible platform. I would recommend getting aquainted with it before complaining about its
Re:Technical details needed! (Score:2)
And Leopard has DTrace (Score:5, Interesting)
Well, let's say as exciting.
Re:And Leopard has DTrace (Score:2)
NOOOOOOO #@$#$@ (Score:4, Insightful)
Garbage collection is a step backward, IMO, but every language seems to be moving in this direction. I really do believe that resource awareness is crucial to efficient programming. Garbage collection encourages lazy programming habits, which I've seen in quite a few Java developers. Bad habits, once bred, are hard to get rid of.
Now, instead of profiling memory for leaks, you can profile the garbage collector, which I predict will be just as much of a headache as tracking down a memory leak. In the end, little work is saved, at least from my experience debugging other developers' Java applications. I won't know for sure until I play with XCode 3.
Re:NOOOOOOO #@$#$@ (Score:2)
Garbage collection can also lead to unpredictability.
I detest it when a GUI pauses for no good reason, just because the runtime library decided to do a garbage collection at that point. It breaks some of the cardinal rules of good interface design; predictability and responsiveness.
---
Don't be a programmer-bureaucrat; someone who substitutes marketing buzzwords and software bloat for verifiable improvements.
Re:NOOOOOOO #@$#$@ (Score:3, Insightful)
And I detest it when a GUI pauses for no good reason, just because the manual storage allocator has needlessly held on to extra storage and the application is now forced to go to virtual memory.
Garbage collection can also lead to unpredictability.
There are different kinds of garbage collectors: some are intended for non-interactive programs and minimize long-term CPU overhead, while others give guaranteed real-time performance. There's also a middle ground
Re:NOOOOOOO #@$#$@ (Score:4, Interesting)
There is no need to panic. You can support both reference counting and garbage collection in one run-time, provided the objects are in separate heaps. Whenever there is a reference from reference counting heap to the garbage collected heap, you simply tell the GC that there is a "root" reference inside a reference counting object. The other direction is probably even easier. A conservative GC can discern whether a reference is managed by the GC or not. Otherwise, we can foil a GC's attempt at traversing outside of the GC heap by marking a reference as an integer or by wrapping it in a special binary object that GC does not traverse.
Ever heard of suggestions that global variables are harmful? This is even truer for GC memory management. These globals have roots that persist throughout the lifetime of a program. For this reason, Java programmers seem to suffer more GC problems than a functional language programmer. In fact, the only place you need to look at, in the case of a "GC memory leak," is your global variables.
Unless a GC implementation is flawed, GC does not produce memory leaks. The leaks you are talking about are still technically used by the program but the programmer is not aware of it.
Debugging reference counting is just as much work as debugging malloc/free. In both cases, you need a map tracking the creation, duplication, and consumption of references.
If by efficient programming you also take into account run-time overhead, some implementation of GC is more efficient than some implementation of malloc/free. For example, a copying GC only maintains a "heap top" pointer, and any new object is allocated from heap top only. In contrast to malloc/free implemented as linked list traversal, GC takes O(1) time to allocate, and O(n) time when it runs out of memory; malloc/free always takes O(n) time.
I'm sure other people will fill in the details here if they want to. The point here is that you cannot compare blanket GC with blanket reference counting or malloc/free.
If by efficient programming you mean the time it takes to write code, I believe GC is the winner here, since you forget you're using memory altogether.
Re:NOOOOOOO #@$#$@ (Score:3, Funny)
First of all, even dumb mallocs do not 'always' take O(n) time.
And comparing GC to a craptardic mallocation strategy is like comparing any sorting algorithm against bubble sort.
Re:NOOOOOOO #@$#$@ (Score:2)
Re:NOOOOOOO #@$#$@ (Score:3, Interesting)
Secondly, I challenge you to describe a situation in which you can leak memory in Java despite throwing away the reference to the object in question. I'm
Re:Sonny, since the effect is the same (Score:3, Interesting)
Oh, and BTW, your use of "sonny" is unsurprising, given your last experience with the Java GC was version 1.2. Maybe try updatin
Re:NOOOOOOO #@$#$@ (Score:5, Insightful)
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.
Re:Can't retrofit safety (Score:2)
Quite right. And that's why I pointed out in another thread that I think that adding garbage collection to Objective C is just a gimmick unless Apple has made substantial changes to other parts of Objective C as well.
Producing optimized code isn't easier with garbage collection, but producing slow code is. Meaning that the routine majority of your coding gets done sooner and you
Re:NOOOOOOO #@$#$@ (Score:5, Informative)
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.
Re:NOOOOOOO #@$#$@ (Score:4, Insightful)
You're missing the point, which is to make it easier to model a language mathematically. The easier the model is to reason with, the fewer errors you'll have. It frees your mind from petty concerns that arise from having an overly-complex language model.
We'll go back to Lisp to elucidate this, which has always cleaned up after itself. Lisp has a very strict underlying mathematical model. Consider math for a moment. Once you define something, is it ever undefined? If you've stated a truth, is it ever not true?
No. Likewise, in languages with garbage collection, once you create something, it exists, theoretically, forever. In the theoretical language model, memory is infinite. The fact that something cleans up stuff that isn't referenced because we happen to be using state machines rather than true Turing machines and need the memory back is merely a necessity of living in the real world.
There's a beauty and an elegance about "garbage collection" (i.e. the more-mathematical infinite memory model) that you're totally missing out on.
Mathematically speaking, mutable variables are a bad habit. As you say, bad habits, once bred, are hard to get rid of. Can you break this one? You don't have to, just think about it. The point is, I'm challenging you to expand your mind a bit and understand that what you hold dear isn't all there is in the world of programming.
Where did this piece of utter tripe come from? Haven't you ever created a circularly-linked list? Must everything in memory be a tree?
Re:NOOOOOOO #@$#$@ (Score:2)
It's clever and it works well most of the time, but I wouldn't call it "elegant". Witness the frequent debates on how to properly write accessor methods.
Garbage collection is a step backward, IMO, but every language seems to be moving in this direction.
And with good reason. As Paul Graham has noted, eventually higher levels of abstraction always win.
I really do believe that resource awareness is crucial to efficient pr
Garbage Collection and Apple (Score:3, Interesting)
I love Objective-C and Apple (NeXT) API's. However, while garbage collection does make it "easier" to write software, I have GREAT fears about people not leaning to clean up after themselves.
Case in point was a University project I did involving robots. Everyone happy sets about coding there little robots in Java, write some simulators, then write the actual robots logic, all in wonderful cross platform Java. Que 100 students pondering why real thing ran for 20seconds then started beeping at them. I spent a LONG time trying to explain to people that with 64k of memory, and NO garbage collection (yey "special" Java) you cannot just keep creating temporary objects at will and hoping mummy will clean up.
I think its super that Apple will be even easier to write for, but please make sure your know how to clean up after yourself before you start coding, you never know when silicon mummy will be on holiday.
NB. Not sure I mean "easier" to write software, maybe "allows you to write with a little more of your brain unplugged".
Re:Garbage Collection and Apple (Score:2)
It's a fact that people don't clean up properly after themselves. Without garbage collection, when they don't, software crashes unpredictably. With garbage collection, at worst, it runs more slowly.
I spent a LONG time trying to explain to people that with 64k of memory, and NO garbage collection (yey "special" Java) you cannot just keep creating temporary objects at will and hoping mummy will clean up.
Well, and once people start prog
Re:Garbage Collection and Apple (Score:2)
Not my students. I'm one of them... but they hunt in packs. If you have the only working robot they decend on you like jackals...
As for when to teach people how to manage memory, I think that in a University it should be done as soon as possible, if education worked by "leave it till they need it" then I wouldn't have learned half the exciting stuff I know now... leaving learning often just results in missing out.
PS. I'm pretty sure that the Java engine could have had garbage collection,
Apple innovates... (Score:3, Funny)
cpu/human trade off (Score:2)
Re:cpu/human trade off (Score:2)
Determinism.
many people miss the point of GC (Score:3, Insightful)
The purpose of garbage collection is to make languages safer. If Objective C 2.0 has additional features to make it safer (variable initialization, pointer checks, etc.), then garbage collection will help it. Otherwise, it's just a gimmick.
Unfortunately, from Apple's web page, it's difficult to see what exactly they did; adding garbage collection to Objective C in a useful and correct way is a nearly intractable problem, and I won't believe that they succeeded until I see more data.
Customers don't like to pay for memory leaks (Score:2)
Ummm... Boehm (Score:2)
The "big deal" regarding ObjC 2.0 is the syntax "enhancements" I'll bet. So far, I haven't seen any examples of "ObjC 2.0" code.
GJC
ObjC Referencing Counting In A Nutshell (Score:3, Informative)
[[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.
Re:...... Garbage Collection.... (Score:2)
isn't that what the Autorelease pool is for? or is this more automatic?
Not sure if you're joking, but... (Score:4, Informative)
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]
ObjC 2.0 does real garbage collection, like java's. No retain, no release - just automatic management when objects fall out of context.
Simon
Re:Not sure if you're joking, but... (Score:2)
I never really read up on garbage collection, but from the way it was originally explained to me, when I learned ObjC after learning Java, I kinda grouped the autorelease pool in my mind with Java's garbage collection.
I guess ObjC's is just a kind of slapped together GC-like implementation?
Re:Not sure if you're joking, but... (Score:2)
Simon
That is incorrect. (Score:2)
In other words, I don't know what this "real" garbage collection brings to the party.
Re:That is incorrect. (Score:2)
If you want to have threads, and you call NSThread's detachNewSelector:toTarget:withObject: method, you have to set up the autorelease pool yourself. If you have an infinite loop in a background thread, your application will probably eventually crash, simply because you've never freed any objects in the autorelease pool in
Re:...... Garbage Collection.... (Score:2)
In response to the naysayers... (Score:5, Informative)
Re:In response to the naysayers... (Score:3, Insightful)
Library only GC (Score:2)
Re:uh, neat.... (Score:3, Insightful)
At the end of the day Apple aren't really catering for the top programmers here who will write good programs no matter what. It'll hel
Re:uh, neat.... (Score:5, Insightful)
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:uh, neat.... (Score:3, Informative)
Re:uh, neat.... (Score:2)
Re:uh, neat.... (Score:2)
Here's the funny thing, though: Objective-C is supposed to be like SmallTalk... and SmallTalk has garbage collection!
Remember, garbage collection isn't just Java. It's been around much longer than that in lanugages like SmallTalk and LISP. And as with everthing except ActiveX, it's good for the uses it's designed for.
Bring back the good old days! (Score:2)
Or if you're a quiche eater...
Your knowledge of GC is 10 years out of date (Score:4, Insightful)
"A major reason for this is that the garbage collector allows the runtime system to amortize allocation and deallocation operations in a potentially advantageous fashion." -- http://en.wikipedia.org/wiki/Garbage_collection_(
--
Carnage Blender [carnageblender.com]: Meet interesting people. Kill them.
Re:Your knowledge of GC is 10 years out of date (Score:3, Insightful)
Re:Your knowledge of GC is 10 years out of date (Score:3, Interesting)
A modern Java virtual machine uses a compacting GC. This allows it to perform the following super-duper, evil, highly intensive allocation procedure for an object of N bytes:
In what way exactly is this more expensive than malloc? That's right, it's far less expensive than malloc. It's just as expensi
Re:Your knowledge of GC is 10 years out of date (Score:2)
Re:Your knowledge of GC is 10 years out of date (Score:4, Interesting)
Greater throughput at the expense of latency. GC stops the world.
"A major reason for this is that the garbage collector allows the runtime system to amortize allocation and deallocation operations in a potentially advantageous fashion."
I would like to offer you a bank account with 50% interest amortized over 500 years. I regret that you will not receive your first interest payment until the 500 years are up.
The point is that amortized performance gives you no control over when you're going to take the hit. That's OK if you only care about throughput.
Re:Your knowledge of GC is 10 years out of date (Score:2)
I'll get more excited about concurrent collectors when they find their way into the mainstream and prove themselves.
Re:Your knowledge of GC is 10 years out of date (Score:2)
Re:uh, neat.... (Score:2)
No kidding. What's next... automatic IP packet collision avoidance? No thanks, I roll my own.
Xcode 3.0 isn't released yet (Score:2)
There's a few additional details and a screenshot up on Apple's site:
http://www.apple.com/macosx/leopard/xcode.html [apple.com]
-Mark
Re:XCode 3.0 (Score:2)
Re:Hacks and Novices Rejoice! (Score:4, Funny)
Shudder.
posted wirelessly via abacus and smoke signals
Re:Hacks and Novices Rejoice! (Score:3, Insightful)
I grew up programming in assembler and C. Even dinosaurs like myself know that memory allocation is not an issue for 99% of software projects.
Get with the new century dude.
Re:Hacks and Novices Rejoice! (Score:2)
Re:Hacks and Novices Rejoice! (Score:3, Interesting)
That said, *yes* stack variables allow a certain amount of programmer optimisation not explictly available to Java programmers, *but* that is all optimisation that the JVM can do via escape analysis (but you knew that, didn't you?). What's more, that kind of analysis can allow a JVM to optimise values onto the stack depen
Re:Hacks and Novices Rejoice! (Score:2)
Oh no, now hobbyist Java programmers like me will be able to more easily learn Objective-C and write native Mac apps for our own amusement that you will never have to use or even acknowledge. I feel your pain.
Re:Hacks and Novices Rejoice! (Score:2)
Re:Hacks and Novices Rejoice! (Score:2)
I mean, of course you can use them for simple assignment, but the whole attraction of creating operators in stead of normal member functions is to be able to set up complex expressions with them, ineveitably creating quite a lot of fleeting intermediate results that you never even get a handle to.
Re:Why not Objective C? (Score:3, Interesting)
Because it's 'a failed language'. If they could come up with a rebrand (AJAX) or take the concepts and give it a syntactic revamp (maybe based round Ruby) they'd be well away, but the predominant line has been C to C++ to Java (and now C-sharp) - and only recently have Java developers begun to demand the features of a true OO language.
To be fair, there were good performance reasons why C++ won over Smalltalk regardless of it's
Oh dear, where to start ? (Score:5, Informative)
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++...
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.
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.
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.
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
You need to read the PDF manual [apple.com]. There's a lot of stuff you're saying as fact, that is simply wrong.
Simon
Re:Oh dear, where to start ? (Score:2)
Re:Oh dear, where to start ? (Score:2)
If you're trying to tell me that the generic containers of C++ come with zero cost, I have a bridge to sell you. At any level, you can make an abstraction or you can code to that level. The standard CS joke is that any problem in any language can
Re:Why not Objective C? (Score:4, Interesting)
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:Why not Objective C? (Score:2)
Like most of Boost, it's a hack. An elegant, beautiful hack but a hack nonetheless, meant to implement in code missing features built-in in other languages.
Reading the code in the Boost libraries gives me headaches -- and often gives various compilers fits. (Templated templates, anyone? I had to find documentation for THAT in a footnote in the appendix to chapter on templates Stroustrup's book, and the Solaris compiler didn't support it ful
Re:Why not Objective C? (Score:2)
Re:why is it.... (Score:3, Interesting)
As far as I can see it's still a Cocoa app, so while it's certainly possible (we know the Next frameworks would run on top of multiple kernels) it is unlikely unless Apple decided to open up the layers above Darwin (unlikely). Alternatively, resource could be put into the GnuStep project, but overall there seems very little interest in it. (The non-Apple Obj-C community is tiny).
DTrace is currently only on Solaris and BSD (at least last I knew).
I'd imagine there would
Re:why is it.... (Score:2)
He probably meant x86, but that's not exactly "new" as in "it just happened" - XCode has supported x86 for a while now.
"Currently", yes, but the XCode 3.0 page [apple.com] says "Many such Xray instruments leverage the open source DTrace, now built into Mac OS X Leopard."
Re:Uh... Great! Just... great... (Score:2)
If you really did buy, read, and understand those "$50 USD books" (which is doubtful, given your post), you can write programs exactly the same as you do now. If you want to take advantage of garbage collection, you can do so at your own pace, and the included documentation and examples will be more than enough to learn from.
Re:Uh... Great! Just... great... (Score:2)
Re:Uh... Great! Just... great... (Score:2)
Re:Uh... Great! Just... great... (Score:2)
I think he started down that road, and don't know where he stopped, but I don't believe he has made his way through to the end yet. I think his question was sardonic and based on unfou
Re:Yay! More Bloated Crappy Code (Score:4, Insightful)
I love listening to people complain about GC. Of course *they* are super-programmers that don't need any of this stuff, because their code never has *any* problems in it. But here I am with all these leaky programs. They leak memory all over the place and don't care. Why? Because I don't *need* to care about memory, everyone has 1GB anyway.
Re:Yay! More Bloated Crappy Code (Score:2)
Hmm. Well, if our visual library leaks there's nothing I can do about it. But I know for a fact that our business logic doesn't leak. It was fairly easy to prove.
(I used to be able to prove the interface didn't leak either, but the company who produced the tool I used for that has disappeared.)
Re:Support for a Java-like messaging syntax? (Score:2)
[myThing putzAboutWithName:"Bill" age:28 pizza:"pepperoni and mushroom" beer:"porter" shoes:"wingtip" inseam:34]
vs.
myThing.putzAboutWithNameAgePizzaBeerShoesInseam(
Re:Support for a Java-like messaging syntax? (Score:2)
You could do: [myThing putzAboutWithName:"Bill"
What ever happened to simple short code? C coding wasn't about duplicating a GUI at your fingertips. None of the better dynamic languages s