Obj C is C with some syntax extensions - I'm not trying to pedantic, ObjC code tends to look like a Reese's Peanutbutter cup - there you are, happily eating your chocolate, errr...., reading C code, when suddenly you discover someone mixed some Smalltalk into it.
Apple has always pushed their ObjC changes back to gnu - but that doesn't mean various users/distros provide a gcc that has those features enabled.
(checking my ubuntu partition...)
Yeah, Ubuntu, at least, includes support for compiling objective C files. I doubt the Ubuntu glibc includes support for retain/release OR this new gcc though. Last time I looked at the source code, the Darwin version of malloc() was utterly different than the generic version. The Darwin version of malloc has some very interesting features; for example, it maintains a sanity-checking system that keeps you from free()-ing memory to a heap that wasn't malloced() from that heap. Those features actually caused me some serious headaches when porting Linux DMA code to Mac, but we were also able to use those features to overcome those headaches.
I have no idea which malloc implementation is faster, but Darwin's generally seems more robust.
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.
So, the GC is a different allocation zone? Do you use the various *withZone functions when allocating for the GC, or does the GC become the default and you use *withZone functions to get the retain release model?
The problem isn't Objective C, it's that people choose the wrong language for the job.
I'll be the first to admit that Java is easy to use and has some powerful features. At the same time, I wouldn't write an OS or a device driver in it. Objective C, like C++, was an attempt to retrofit OO features onto a highly machine-oriented language. In the abstract, I think that is a foolish thing to do but, compared with the original C++ grammar, I think ObjC was a better job.
C++ has improved a lot since then, but I still don't think I'd choose to use an OO language for low level work, any more than I'd use straight C to design a web site.
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 willing to bet you can't.
I can. Back when 1.2 was the sweet hotness I was asked to write a desktop app to interface with some middle ware. It had a habit of expanding to consume the entire available heap and then chugging very slowly to GC all at once. The fact that I couldn't force it to garbage collect more frequently eventually made us abandon the project. It simply wasn't usable.
It's just that people coming from straight C aren't used to it.
I'll be the first to admit that I've been caught by releasing things early, or worried that I wasn't releasing things that could be - but once you get into the habit of retaining things you want to keep and releasing them when you don't want them anymore it's no harder than malloc and free.
You'd have to provide cites for GC being "often faster". I really can't see how scanning the stack and globals for pointers that might either point to an entity or, worse, to the interior of an entity can be fast.
I spend my days working with code that does lots and lots of pointer math, where the pointers are nowhere near the beginnings of the buffers; I can't see how GC would do anything but accidentally free memory that some DMA operation is still using.
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.
Right, right. And training wheels make it easier to ride a bike. Doesn't mean you should leave them on, though.
The malloc code in OS X supports what are called "zones" - each zone is it's own heap and function library for managing the heap. They're probably just swapping the default allocator for one that supports GC.
I'm still unsure about the value of this, but I don't think it would require changes to the applications themselves.
I've been coding C for just under twenty years and I can tell you, you're wrong. Modern GC's allocate faster than C's malloc routine.
If you've been coding for 20 years, but failed to realize that malloc() is not part of C, but part of libc - and varies from OS to OS and from compiler to compiler, then I don't know how I can believe your assertions about performance.
Linux malloc() is based on the glibc and is slightly brain damaged from my point of view, because it can't be properly overridden for debugging or dma operations (it has debug hooks but they aren't thread safe). OS X malloc() is a different implementation that actually supports multiple heaps and allows for the different heaps to have different allocation/release strategies.
There are other algorithms as well, which any book on the subject would tell you.
Although, you still risk chasing an invalid pointer if you hang onto an object after you release it.
If you forget to release, you leak.
GC is unpredictable and has caused huge problems for me when I've worked with Java desktop applications in the past - Java apps ballooning up to large sizes then freezing for several seconds as the GC finally wakes up - it wasn't pretty.
Perhaps things have changed since Java 1.2; but that's certainly been my experience. Besides, scanning every pointer and handle in an application just to see if it still points to something is an awfully ugly hack to get around programmer stupidity.
Actually I think I am correct - the reason the event loop is important is that it always creates an autorelease pool at the start of the loop, and destroys the pool at the end of the loop
Hrm.
So, I googled around and I see both explanations on the web - the NSAutoReleasePool class seems to do as you describe; yet my developer books and past experience are as I describe - the heap/malloc zone used for default allocations is an "autorelease pool".
Taking pictures of random animals is not what I was talking about. In BG&E you're basically a freelance journalist whose trying to uncover a scandal. Yes, you can take pictures of random stuff as a side quest, but collecting evidence and submitting it to the local newspaper is the main story line.
I enjoyed playing BG I thought using the camera to take pictures of "bad stuff" and then using the pictures to create public sentiment was a nice change of pace from the superman-vs-lex-luthor model of most of these games.
Gramma buys my kid a game, she doesn't know it's not suitable for a kid because people like you are opposed to put ratings on boxes.
Exactly how do you expect me to know the game isn't suitable, before my kid has a chance to play it? For example, at gramma's house?
I like people who are willing to invoke parental super powers and other ridiculous logical contortions because they dislike who simply putting a piece of information on a box.
Yeah - I'd tell you the story of what happened when I saw the original Jaws the week it opened in the movie theaters, but I don't want to embarass myself.:-P
There was actually an old adventure game for the Amiga called "The Uninvited" that managed to completely creep me out - as a 22 year old adult - until I realized that they really were using subliminal images to try to scare the crap out of the player.
I pulled a 24 hour stint playing Final Fantasy X-2 before I was sure my son really didn't want to play a game where you had to dress girls up in just the right outfit for the big boss fight...
See, I don't just have to worry about games I give my kids (rarely) or that they buy with their allowances (frequently) - I also have to worry about games that gramma buys them, and uncle joe who heard that gta was cool, and so on.
The ratings at least provide computer illiterate gramma with clue that maybe Resident Evil isn't an appropriate choice for a 7 year old.
Personally, I use one all the time and for long coding sessions they are essential for preventing pain in my left wrist. I can type equally quickly on both, but when I use my laptop keyboard the discomfort builds up pretty quickly.
I'm still gaping over the use of "caretaker" to describe a parent or guardian. I have this image of children neatly planted in little rows, while Charlie the Caretaker comes by and waters them once a day.
Slashdot Mirror
Obj C is C with some syntax extensions - I'm not trying to pedantic, ObjC code tends to look like a Reese's Peanutbutter cup - there you are, happily eating your chocolate, errr...., reading C code, when suddenly you discover someone mixed some Smalltalk into it.
Apple has always pushed their ObjC changes back to gnu - but that doesn't mean various users/distros provide a gcc that has those features enabled.
(checking my ubuntu partition...)
Yeah, Ubuntu, at least, includes support for compiling objective C files. I doubt the Ubuntu glibc includes support for retain/release OR this new gcc though. Last time I looked at the source code, the Darwin version of malloc() was utterly different than the generic version. The Darwin version of malloc has some very interesting features; for example, it maintains a sanity-checking system that keeps you from free()-ing memory to a heap that wasn't malloced() from that heap. Those features actually caused me some serious headaches when porting Linux DMA code to Mac, but we were also able to use those features to overcome those headaches.
I have no idea which malloc implementation is faster, but Darwin's generally seems more robust.
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.
So, the GC is a different allocation zone? Do you use the various *withZone functions when allocating for the GC, or does the GC become the default and you use *withZone functions to get the retain release model?
The problem isn't Objective C, it's that people choose the wrong language for the job.
I'll be the first to admit that Java is easy to use and has some powerful features. At the same time, I wouldn't write an OS or a device driver in it. Objective C, like C++, was an attempt to retrofit OO features onto a highly machine-oriented language. In the abstract, I think that is a foolish thing to do but, compared with the original C++ grammar, I think ObjC was a better job.
C++ has improved a lot since then, but I still don't think I'd choose to use an OO language for low level work, any more than I'd use straight C to design a web site.
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 willing to bet you can't.
I can. Back when 1.2 was the sweet hotness I was asked to write a desktop app to interface with some middle ware. It had a habit of expanding to consume the entire available heap and then chugging very slowly to GC all at once. The fact that I couldn't force it to garbage collect more frequently eventually made us abandon the project. It simply wasn't usable.
It's just that people coming from straight C aren't used to it.
I'll be the first to admit that I've been caught by releasing things early, or worried that I wasn't releasing things that could be - but once you get into the habit of retaining things you want to keep and releasing them when you don't want them anymore it's no harder than malloc and free.
You'd have to provide cites for GC being "often faster". I really can't see how scanning the stack and globals for pointers that might either point to an entity or, worse, to the interior of an entity can be fast.
I spend my days working with code that does lots and lots of pointer math, where the pointers are nowhere near the beginnings of the buffers; I can't see how GC would do anything but accidentally free memory that some DMA operation is still using.
And yet, you are the one claiming that C's malloc is slower. Since malloc isn't a single thing, how can you make that claim?
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.
Right, right. And training wheels make it easier to ride a bike. Doesn't mean you should leave them on, though.
The malloc code in OS X supports what are called "zones" - each zone is it's own heap and function library for managing the heap. They're probably just swapping the default allocator for one that supports GC.
I'm still unsure about the value of this, but I don't think it would require changes to the applications themselves.
I've been coding C for just under twenty years and I can tell you, you're wrong. Modern GC's allocate faster than C's malloc routine.
If you've been coding for 20 years, but failed to realize that malloc() is not part of C, but part of libc - and varies from OS to OS and from compiler to compiler, then I don't know how I can believe your assertions about performance.
Linux malloc() is based on the glibc and is slightly brain damaged from my point of view, because it can't be properly overridden for debugging or dma operations (it has debug hooks but they aren't thread safe). OS X malloc() is a different implementation that actually supports multiple heaps and allows for the different heaps to have different allocation/release strategies.
There are other algorithms as well, which any book on the subject would tell you.
Although, you still risk chasing an invalid pointer if you hang onto an object after you release it.
If you forget to release, you leak.
GC is unpredictable and has caused huge problems for me when I've worked with Java desktop applications in the past - Java apps ballooning up to large sizes then freezing for several seconds as the GC finally wakes up - it wasn't pretty.
Perhaps things have changed since Java 1.2; but that's certainly been my experience. Besides, scanning every pointer and handle in an application just to see if it still points to something is an awfully ugly hack to get around programmer stupidity.
Actually I think I am correct - the reason the event loop is important is that it always creates an autorelease pool at the start of the loop, and destroys the pool at the end of the loop
Hrm.
So, I googled around and I see both explanations on the web - the NSAutoReleasePool class seems to do as you describe; yet my developer books and past experience are as I describe - the heap/malloc zone used for default allocations is an "autorelease pool".
Anything in the autorelease pool with a retain count of *zero* is automatically freed on the next invocation of the main event loop.
In other words, I don't know what this "real" garbage collection brings to the party.
Taking pictures of random animals is not what I was talking about. In BG&E you're basically a freelance journalist whose trying to uncover a scandal. Yes, you can take pictures of random stuff as a side quest, but collecting evidence and submitting it to the local newspaper is the main story line.
I enjoyed playing BG I thought using the camera to take pictures of "bad stuff" and then using the pictures to create public sentiment was a nice change of pace from the superman-vs-lex-luthor model of most of these games.
Gramma buys my kid a game, she doesn't know it's not suitable for a kid because people like you are opposed to put ratings on boxes.
Exactly how do you expect me to know the game isn't suitable, before my kid has a chance to play it? For example, at gramma's house?
I like people who are willing to invoke parental super powers and other ridiculous logical contortions because they dislike who simply putting a piece of information on a box.
Yeah - I'd tell you the story of what happened when I saw the original Jaws the week it opened in the movie theaters, but I don't want to embarass myself. :-P
There was actually an old adventure game for the Amiga called "The Uninvited" that managed to completely creep me out - as a 22 year old adult - until I realized that they really were using subliminal images to try to scare the crap out of the player.
Frankly, we're having enough zoological issues around the house without adding reptiles, thanks very much.
Although, a good garden snake might keep the spider population down....
Hmmm...
As I posted elsewhere, you can't tell your kid they aren't allowed to have nightmares because the horror game wasn't appropriate for their age.
I'm happy with the current ESRB system - unlike the guy I was responding to, who stated that putting a rating on a game box is censorship.
I pulled a 24 hour stint playing Final Fantasy X-2 before I was sure my son really didn't want to play a game where you had to dress girls up in just the right outfit for the big boss fight...
Thanks for putting words in my mouth.
See, I don't just have to worry about games I give my kids (rarely) or that they buy with their allowances (frequently) - I also have to worry about games that gramma buys them, and uncle joe who heard that gta was cool, and so on.
The ratings at least provide computer illiterate gramma with clue that maybe Resident Evil isn't an appropriate choice for a 7 year old.
Why did you start using an ergo keyboard?
Personally, I use one all the time and for long coding sessions they are essential for preventing pain in my left wrist. I can type equally quickly on both, but when I use my laptop keyboard the discomfort builds up pretty quickly.
I'm still gaping over the use of "caretaker" to describe a parent or guardian. I have this image of children neatly planted in little rows, while Charlie the Caretaker comes by and waters them once a day.