Garbage collection?

R

Rick

Hi,

My question is.. if Lisp, a 40 year old language supports garbage
collection, why didn't the authors of C++ choose garbage collection for
this language? Are there fundamental reasons behind this? Is it because
C is generally a 'low level' language and they didn't want garbage
collection to creep into C++ and ruin everything?

Just wondering :)

Rick
 
K

Karl Heinz Buchegger

Rick said:
Hi,

My question is.. if Lisp, a 40 year old language supports garbage
collection, why didn't the authors of C++ choose garbage collection for
this language?

You have to ask Mr. Stroustroup on this one.
He has written a book about why C++ looks and acts the way it does.
Locate his website, I think there is a description of that book.
Are there fundamental reasons behind this? Is it because
C is generally a 'low level' language and they didn't want garbage
collection to creep into C++ and ruin everything?

Ts, ts, ruin everything.

But it's true. C and C++ is used a lot controlling software.
Imagine a nuclear power plant. Imagine that there is a malfunction
within the reactor. Further imagine that your software has detected
that malfunction and is going to shut down the reactor in an orderly
fashion. The software has waited until there is no other choice to
shutdown and it knows that this may be time critical. The software
starts the shutdown process .... and then the garbage collector kicks in.

That said: C++ is powerful enough that there are garbage collectors around.
Just google for them if you feel the need to use one.
 
D

Dan W.

Hi,

My question is.. if Lisp, a 40 year old language supports garbage
collection, why didn't the authors of C++ choose garbage collection for
this language? Are there fundamental reasons behind this? Is it because
C is generally a 'low level' language and they didn't want garbage
collection to creep into C++ and ruin everything?

Just wondering :)

Rick

I, for one, don't want anything to do with GC, thanks! The day C++
forces GC on me, I'll move on to Assembler if I have to.
 
N

Nemanja Trifunovic

Rick said:
Hi,

My question is.. if Lisp, a 40 year old language supports garbage
collection, why didn't the authors of C++ choose garbage collection for
this language? Are there fundamental reasons behind this? Is it because
C is generally a 'low level' language and they didn't want garbage
collection to creep into C++ and ruin everything?

Just wondering :)

Rick

Why don't you ask Dr Bjarne Stroustrup :)

http://www.research.att.com/~bs/bs_faq.html#garbage-collection
 
A

Adam Fineman

Karl Heinz Buchegger wrote:
Imagine that there is a malfunction
within the reactor. Further imagine that your software has detected
that malfunction and is going to shut down the reactor in an orderly
fashion. The software has waited until there is no other choice to
shutdown and it knows that this may be time critical. The software
starts the shutdown process .... and then the garbage collector kicks in.
<snip>

This actually describes a need for a hard real-time OS. GC and
real-time are not inherently incompatible (there are real-time JVMs out
there), and not having GC is obviously not sufficient to ensure meeting
deadlines.

I understand the point you're making, Karl. I'm just picking on your
example. Real-time doesn't mean 'real fast', it just means 'real
predictable'.

Suffice it to say that GC will eat cycles, and if C++ were to provide GC
in the same manner as Java, then there would be no way to avoid spending
time doing garbage collection in a C++ application.

- Adam
 
D

David Fisher

Rick said:
My question is.. if Lisp, a 40 year old language supports garbage
collection, why didn't the authors of C++ choose garbage collection for
this language? Are there fundamental reasons behind this? Is it because
C is generally a 'low level' language and they didn't want garbage
collection to creep into C++ and ruin everything?

I guess the principle is not to take decisions about things like memory
management out of the programmer's hands ... C++ was designed to stay pretty
much as efficient as C. There is also a principle of "extensibility via
libraries" instead of adding features to the language (if you want a garbage
collector, you can always add one; the "new" operator was made overloadable
so that memory management could be done however you like). The disadvantage
is that some things would be much easier to use if they were built into the
language, eg. a "for each ..." statement (with a local body that allows
break & continue), a completely polymorphic type (like the "any" type in the
boost library), and (optional) garbage collection.

Here are some web pages related to garbage collection in C++:

http://www.hpl.hp.com/personal/Hans_Boehm/gc/index.html
(lots of garbage collection resources)

http://www.jelovic.com/articles/cpp_without_memory_errors_slides.htm
(a "safe pointer" type)

- neither of which I have actually tried, but they look good ...

I also read about a library which lets you group a set of objects together
and free them all at once (much faster than one at a time), but I can't find
it right now. Has anyone else heard of this library ?

David F
 
R

Rick

Thanks David,

David said:
I also read about a library which lets you group a set of objects together
and free them all at once (much faster than one at a time), but I can't find
it right now. Has anyone else heard of this library ?

Yup.. this is what "region-based memory management" is all about - first
introduced by Tofte and Talpin.

regards,
Rick
 
S

stelios xanthakis

Xenos said:
Amen, brother!

Amen ^ 3.

GC is the concept of mopping the floor and putting the dirt under the carpet.
Furthermore, today, with all the great tools like valgrind, you can
detect all memory related bugs with a couple of good testcases.

Stelios
 
R

Rolf Magnus

Adam said:
Karl Heinz Buchegger wrote:

<snip>

This actually describes a need for a hard real-time OS. GC and
real-time are not inherently incompatible (there are real-time JVMs
out there), and not having GC is obviously not sufficient to ensure
meeting deadlines.

I understand the point you're making, Karl. I'm just picking on your
example. Real-time doesn't mean 'real fast', it just means 'real
predictable'.

I think that was just his point. The GC kicks in at unpredictable times
and needs an unpredictable amount of time. It is just as bad for real
time as e.g. swapping is.
Suffice it to say that GC will eat cycles, and if C++ were to provide
GC in the same manner as Java, then there would be no way to avoid
spending time doing garbage collection in a C++ application.

Right.
 
A

Adam Fineman

Rolf said:
Adam Fineman wrote:




I think that was just his point. The GC kicks in at unpredictable times
and needs an unpredictable amount of time. It is just as bad for real
time as e.g. swapping is.
<snip>

And my point was that GC and real-time are not incompatible, in that
there are real-time JVMs (with garbage collection) out there. In other
words, on these implementations, GC is only allowed to kick in at
predictable times and run for a predictable amount of time.

- Adam
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,151
Messages
2,570,854
Members
47,394
Latest member
Olekdev

Latest Threads

Top