John a question,
Although I bought the first of many Apple computers in 1980 and have never owned a PC, I spend my workaday life (I should say did as I just retired after 39 years) immersed in a non Apple environment. Most of my career I was an IBM Mainframe Systems Programmer (describes function not title) so I am quite familiar with assembly languages. I have not worked on any micro lnguages (PC or Apple) aside from some scripting. From the article I think I understand "Garbage Collection" to be Memory management and the alloc dealloc to be my world's "getmain freemain". If this is accurate does the change from C+ to C+ 2.0 which has Garbage Collection automated allow the mixture of automated Garbage Collection and explicit memory management (alloc dealloc)?
Thanks
br

Please, that's what our mothers/wives want us to do.

C++ 2.0? Never hear of it. (Bjarne, what have you done this time?) But I've wondered if Objective C solved the partial template specialization issues with most C++ preprocessors.

Any of you Photoshop using Mac-o-philes know the answer?

Seriously dude, check these out:
http://theocacao.com/document.page/258
http://theocacao.com/document.page/261

I think what he means by garbage collection in this context is automatic memory and array allocation, which can grow automatically as needed, and is automatically deallocated when the context of the variable terminates. I would expect the runtime environment to also support explicit memory management via alloc/dealloc.

Quote

Guest wrote:
If this is accurate does the change from C+ to C+ 2.0 which has Garbage Collection automated allow the mixture of automated Garbage Collection and explicit memory management (alloc dealloc)?
Thanks
br

I believe so, yes. I know that you can at least turn off garbage collection and rely strictly on the old manual management if you prefer. I assume that mixing is just fine, too, and you can manually clean up whatever you want, and let the garbage collector take care of the rest. However, I'm not sure I've seen that last part explicitly stated anywhere. I think it's a safe assumption, though.

(I assume by "C+" you mean "Objective-C".)

Oh, one more thing: I think (not 100% sure) that this new garbage collection applies only to Objective-C objects, not manually malloc'd data. In other words, it replaces (or supplements) the [object release] convention.

Garbage Collection is one of the standard ways to manage the use of memory (RAM) in any program. One advantage of garbage collection is that it can be provided as a service that programmers can simply presume will happen by magic (as in the real world if you pay your taxes). About garbage collection:

The programmer has to allocate a block of RAM (random access memory) cells to hold any piece of information. Each memory cell is numbered with a unique address. He keeps track of the blocks of information with pointers, which are just the address of the (first cell of the) block, stored inside some other block.

Something has to keep track of the pool of free memory. When a piece of information is no longer needed, its memory block needs to be returned to the pool.

If a fault in a program means blocks are not being returned when they are no longer in use, it's called a memory leak. Eventually the program can run out of memory and be unable to deal with new information.

One way the programmer can keep track of when to free a block, is to use a reference count stored in every block. When a pointer to the block is made, one is added to the reference count. When a pointer to the block is removed, one is subtracted. When the count is zero, the block is returned to the pool. This is how Objective C and Realbasic work, I believe. A problem is that programmers have to deal with this throughout their programs. A tricky detail is that circular chains of pointers can become isolated knots of blocks that will never be released.

Garbage collection is an alternative. By periodically tracing through every pointer in the program, the blocks in use are identified. All the others can be freed. Two significant problems: 1. the language (unlike C or C++) must be a "safe" language (like Java) where the garbage collector can know which memory words are pointers, and which are other kinds of data. 2. The garbage collector needs to stop the program while it cleans up, potentially causing periodic freezes in a real time or interactive program.

Summary: Garbage Collection is a popular service for programmers, but it can easily disrupt smooth operations while it's being done.

Quote

sleepygeek wrote:
One way the programmer can keep track of when to free a block, is to use a reference count stored in every block. When a pointer to the block is made, one is added to the reference count. When a pointer to the block is removed, one is subtracted. When the count is zero, the block is returned to the pool. This is how Objective C and Realbasic work, I believe

REALbasic does have garbage collection. Actually, REALbasic is about as automatic as can be. You can't manually manage memory even if you want to. (At least not in version 5, which is the latest version I'm really familiar with.)

When I moved from RB to Cocoa/Objective-C, the whole retain/release thing was very hard to wrap my head around. I have a good grasp of it now, and I'm glad I do, but I will certainly appreciate a little automation to clean up after any careless mistakes I make. (And maybe we'll finally get a version of Safari/WebKit that doesn't leak memory...)