Thread: Class method overloading

Based on his online FAQ answers, I daresay Stroustrup thinks that garbage collection does have its uses in C++, at least as a last resort. Consider the last paragraph of his answer to How do I deal with memory leaks?:

Originally Posted by Bjarne Stroustrup

If systematic application of these techniques is not possible in your environment (you have to use code from elsewhere, part of your program was written by Neanderthals, etc.), be sure to use a memory leak detector as part of your standard development procedure, or plug in a garbage collector.

He does not condemn garbage collection, but states in his answer to Why doesn't C++ have garbage collection?:

Originally Posted by Bjarne Stroustrup

If you want automatic garbage collection, there are good commercial and public-domain garbage collectors for C++. For applications where garbage collection is suitable, C++ is an excellent garbage collected language with a performance that compares favorably with other garbage collected languages.

That FAQ links to Hans-J. Boehm's GC implementation that SevenThunders mentioned.

if a slow language like java can afford overhead of GC, then why a super fast language like C++ has problems with it being inefficient???

Originally Posted by SevenThunders

You are forgetting the fact that you have the overhead of incrementing the reference counter on every assignment, and decrement it for every delete, not to mention the fact that you have to keep overhead around for reference counting.

This dwarfs compared to what a Gabage Collector needs to do.
I tried writing one before but gave up due an unsuitable API for the job.
A GC needs to keep lists in memory about every allocation, and in case in allocates in, like, said pages, that means even more overhead.
And does it need to keep check on how many references? Yep.
So a GC's overhead is far more. Not to mention the time it takes to go through all those lists, create them and manage them.

So you have smart pointers that are reference counted. Again that's just a form of garbage collection! Generational garbage collection is considerably more efficient and universal then reference counting. Reference counting will fail in the presence of cycles, which occur quite often in graph theory.

It is not "just another...". A very light reference counting solution needs to reduce reference count, check if zero, and if yes, delete. And the other way around for when incrementing.
But unlike garbage collection, this is a relatively low overhead.

Freeing a lot of small objects manually or when a sizable function returns also 'blocks execution'.

Yes it does, but it usually dwarfs how much the GC has to free at once time.
And when it does, it needs to go through checking what to free. If the application frees it explicitly, it will always be faster. But freeing a lot of memory is always slow, as you mention. But the application will be faster then the GC.

I agree that compacting is not really backwards compatible with C++, but it does reduce memory fragmentation and improves cache performance.

This is one the main advantages you might say. But then again, Windows also has low-fragmentation heaps, which can do the job for us.

Originally Posted by manav

if a slow language like java can afford overhead of GC, the why a super fast language like C++ has problems with it being inefficient???

Two reasons I can think of:
Destructors are not guaranteed to be called at end of scopes or functions.
GC is a bigger overhead, more complex to manage and use and C++ programmer have pretty much always wanted to control their own memory. The language was built that way from the start, after all.

Originally Posted by manav

if a slow language like java can afford overhead of GC, then why a super fast language like C++ has problems with it being inefficient???

Ever considered that the slowness of Java might, partially, be caused _BY_ the GC. In fact, as I understand it, C++ was invented specifically to avoid the overhead of GC in a simulation program written in Simulua 67 [another language that does GC], as when Bjarne Stroustrup started the LARGE simulation, the GC processing was 80% of the overall runtime. [This was probably a BAD case of GC implementation, but it's still part of why C++ was implemented in the first place].

--
Mats