Thread: C++ Garbage Collector

Due to overcomplicated overhead maker performance killer but very flexible and reuseable design, I need to mix manual and garbage collected memory management in my C++ applications.

Because at some point I can't determine whether an object should be destroyed or not.

I think I need a help from a garbage collector.


Do you use garbage collector?

What is it?

Is it fast?

Is it easy to use (pluggable) and mixable with the manual memory management?

And unrelated question: Is smart pointer a garbage collector?

How is it work anyway?

Thanks in advance by the way.

A smart pointer is not a garbage collector. A smart pointer is usually a reference counted pointer. Each time you create an instance of the smart pointer that points to the same memory, the reference count increases. Everytime an instance to the pointer is destroyed, it decrease the count.
So when the last smart pointer goes out of scope, it frees the memory.
Check out std::tr1::shared_ptr or alternatively boost::shared_ptr.

The overhead of smart pointers are very small and fits right in into the design of C++. Smart pointers can be used exactly like normal pointers.

They also have an advantage over garbage collection: they have deterministic destructors.
What does that mean, you ask? When using a garbage collector, destructors of classes might not be run. Or if they are, it is impossible to predict when.
But with smart pointers, you know that the destructors of objects will run as soon as the last smart pointer goes out of scope.

Thank you Elysia, you are my live savior!

Btw is it guarantee to guard our code from memory leaks?

However I found auto_ptr only not the shared one..

There is one problem with smart pointers: circular references. A points to B, B points to A. This will cause memory leaks and can be solved by using a "weak pointer" in one class to break this chain.
Otherwise there will be NO leaks whatsoever.

no C++ does not have a garbage collector like VB and C#. you have to deal with the garbage yourself.

Originally Posted by Jelte

no C++ does not have a garbage collector like VB and C#. you have to deal with the garbage yourself.

Standard C++ does not come with a garbage collector, but automatic garbage collectors are available.

Originally Posted by Elysia

Otherwise there will be NO leaks whatsoever.

Really? What about this piece of code:

Code:

int main()
{
    shared_ptr< int > x = new int;

    for( ;; )
        ;
}

The variable x is never used, so its memory is wasted. This is called a "leak" under most definitions of "leak" I've ever seen. Reference counts can't help you if you maintain references to objects you will never use again.

This example looks silly, but in a more complicated program this can lead to actual, measurable memory leaks, i.e. the program memory size is increasing although nothing useful is occupying that memory.

This example looks silly, but in a more complicated program this can lead to actual, measurable memory leaks, i.e. the program memory size is increasing although nothing useful is occupying that memory.

Those are actually the worst kind of memory leaks due to being very hard to track down. Tools like valgrind's memcheck don't help because the memory is correctly freed when the application shuts down, so memcheck doesn't detect it. The only program I've found to be helpful in these situations is massif (another valgrind tool) which allows you to examine the heap while the application is running.

Originally Posted by bithub

Those are actually the worst kind of memory leaks due to being very hard to track down. Tools like valgrind's memcheck don't help because the memory is correctly freed when the application shuts down, so memcheck doesn't detect it. The only program I've found to be helpful in these situations is massif (another valgrind tool) which allows you to examine the heap while the application is running.

I've dealt with this before by slightly modifying the shared_ptr<>. Each pointer appends a pointer to itself (pointer to shared_ptr) onto a global list of pointers when it is created, and removes itself from the list when it is destroyed. This means that at any moment I have access to a list of all the shared_ptr objects in memory.

At the end of the program, right before returning from main(), the list will contain only those pointers which still have positive refcounts, i.e. they point to blocks of memory which are referenced somehow. I know that I am about to terminate, so there is no valid reason these references should still exist -- therefore they are leaks. So I traverse this list and increment the refcount of each pointer in the list. Now the memory blocks will not be deleted and memcheck can report them.

Originally Posted by brewbuck

Really? What about this piece of code:

Code:

int main()
{
    shared_ptr< int > x = new int;

    for( ;; )
        ;
}

The variable x is never used, so its memory is wasted. This is called a "leak" under most definitions of "leak" I've ever seen. Reference counts can't help you if you maintain references to objects you will never use again.

This example looks silly, but in a more complicated program this can lead to actual, measurable memory leaks, i.e. the program memory size is increasing although nothing useful is occupying that memory.

This is no "leak" which I thought of, and I wouldn't call it a leak anyway. While x may never be used, it will be released once main ends, and if it doesn't end, then all memory, smart pointers or not will basically leak, if you terminate it somehow.
So, the shared pointer will never fail to release the memory (ie function incorrectly) so long as its destructor is run (and the scenario I stated in the reply above does not occur).
You might say that so long as the above scenario doesn't occur, the shared pointer will function according to specs. It would work as it should. If there is a memory leak still, it's not the smart pointer's fault; it's yours.

This is no "leak" which I thought of, and I wouldn't call it a leak anyway. While x may never be used, it will be released once main ends, and if it doesn't end, then all memory, smart pointers or not will basically leak, if you terminate it somehow.

You are failing to understand his point. The point is that the application can still use up more and more memory as it goes even though smart pointers are correctly used.

Ah. That is not a leak, however. It's just you using more and more resources and not letting the program free them.
It's a good example that you need to be careful with your resource allocation, but it's not the fault of the smart pointers; it's yours.

Whether it is technically a "memory leak" or not is debatable. It has the same effect as a traditional memory leak though, so that's why Brewbuck pointed it out. And no one ever claimed it was the fault of the smart pointer.