So there is manual memory management and few useful reference counting classes.
Is there any chance to use garbage collector in C++?
Is there something that auto_ptr or shared_ptr can't handle other than the cyclic reference problem?
Printable View
So there is manual memory management and few useful reference counting classes.
Is there any chance to use garbage collector in C++?
Is there something that auto_ptr or shared_ptr can't handle other than the cyclic reference problem?
there are a few tools for C++ that do automatic garbage collection.
No, no, I meant: Should we use GC while there is smart pointers?
Sorry for my crappy English.
I believe smart pointers do GC which is the whole point. There is more to GC than just dangling pointers though. There are other resources that need GC. Thread handles for instance.
Garbage collection is generally viewed as something unrelated to smart pointers - in rough terms, GC means that some mechanism automatically releases memory resources that the program is no longer using, but has neglected to release - and does it without specific actions from the program.
In the context of C++, garbage collectors are usually implemented as some library functions that run, potentially independently of your program but accessing its memory space, and do the job of releasing memory when required while your program is running. The Hans-Boehm collector (at this link) is an example.
If you properly ensure that all resources you use in your code are released (one way is using smart pointers correctly) there is no need for garbage collection.
Note also that garbage collectors typically only release memory resources - if your program grabs some other system resource (eg a mutex, a file handle) and forgets to release it, then that resource is still leaked. Since those other resources are often more scarce than memory, such leaks are deadly to functioning of programs - and the most common source of bugs I've encountered in code that relies on the presence of a garbage collector.
Nothing that comes to mind. They are very handy in releasing handles, too, by calling a custom deleter function (well, at least shared_ptr; dunno if auto_ptr has such a function).Quote:
Originally Posted by audinue
So, Is GC useless technology ever made for C++?
GC isn't useless technology, but it isn't that suited for C++.
It's better suited for other languages that are built around it.
I would not recommend a GC for C++. Especially since a GC 99% of the time lacks deterministic destructors and some may not even run destructors at all.
Garbage collection is perhaps like have a park with no bins where several people are employed to go around picking up all the rubbish off the ground.
In the C++ park we have lots of bins, and smart pointers are the tidy people.
Okay there goes my lame attempt at humour for the day...
GC technology seems better with non-machine code languages, ie. runtime languages. I wouldn't know where to begin writing a GC for C++, besides some sort of program similar to a compiler which analyzes all the code, and then generates itself. Which would be strange, and flawed anyway. Proper use of memory and debugging seems to be the best option for C++.
Imagine that you replace all bare pointers with this class:Quote:
Originally Posted by Dae
(Of course, all the surrounding machinery of your typical smart pointer has been omitted).Code:template < typename T >
class TaggedPtr
{
public:
TaggedPtr( T *ptr ) : mPtr( ptr ), mSig( 0xDEADBEEF ), mCheck( 0xDEADBEEF ^ mPtr )
{}
private:
T *mPtr;
T *mSig;
T *mCheck;
};
Now, you can easily scan memory to find active pointers. For each three adjacent values x0, x1, x2 in memory, you check whether x1 == 0xDEADBEEF && x2 == x1 ^ x0. If so, you have found a pointer.
Now that we have a method of finding pointers we need a way of determining the extent of any given object. We can do that by inheriting all classes from a base class which provides a virtual method. Now, the first byte pointed to by any pointer will be a pointer to a vtable, and we can now use RTTI to find the type of the object and therefore its size.
A complication arises because it's possible to have pointers that point to a location WITHIN some other object instead of to the beginning of that object. This is not handled under this model.
Other garbage collectors are more conservative, and simply assume that any 32-bit quantity which would be a valid pointer into the current address space, IS in fact a pointer. This might lead to some objects not being collected which could actually be collected, but that's what "conservative" means anyway.