C++0x Garbage Collection

[Goalie_Ca]

I have been reading (or at least googling) about the potential addition
of optional garbage collection to C++0x. There are numerous myths and
whatnot with very little detailed information.

Will this work be library based or language based and will it be based
on that of managed C++? Then of course there are the finer technical
questions raised (especially due to pointer abuse). Is a GC for C++
just a pipe dream or is there a lot of work in the committee to realise
it.

[Roland Pibinger]

On 23 Jun 2006 23:49:30 -0700, "Goalie_Ca" <go******@gmail .com> wrote:

I have been reading (or at least googling) about the potential addition
of optional garbage collection to C++0x. There are numerous myths and
whatnot with very little detailed information.

C++ needs no garbage collection because it offers something better:
deterministic resource management with destructors. You should have
googled for 'RAII' instead of 'garbage collection'. Actually, RAII is
the 'unique selling proposition' of C++. Introducing GC into C++ would
only make it a worse Java or C#.

Best wishes,
Roland Pibinger

[Mirek Fidler]

Roland Pibinger wrote:

On 23 Jun 2006 23:49:30 -0700, "Goalie_Ca" <go******@gmail .com> wrote:

I have been reading (or at least googling) about the potential addition
of optional garbage collection to C++0x. There are numerous myths and
whatnot with very little detailed information.

C++ needs no garbage collection because it offers something better:
deterministic resource management with destructors. You should have
googled for 'RAII' instead of 'garbage collection'.

Alternatively, go directly here:

http://upp.sf.net

and take a look at sources ;)

You can e.g. start here:

http://upp.sourceforge .net/www$uppweb$vssw ing$en-us.html

RAII rules GC.

Mirek

[Roland Pibinger]

On Sat, 24 Jun 2006 09:58:51 +0200, Mirek Fidler <cx*@volny.cz > wrote:

Roland Pibinger wrote:

On 23 Jun 2006 23:49:30 -0700, "Goalie_Ca" <go******@gmail .com> wrote:

I have been reading (or at least googling) about the potential addition
of optional garbage collection to C++0x. There are numerous myths and
whatnot with very little detailed information.
C++ needs no garbage collection because it offers something better:
deterministic resource management with destructors. You should have
googled for 'RAII' instead of 'garbage collection'.

Alternativel y, go directly here:

http://upp.sf.net
and take a look at sources ;)
You can e.g. start here:
http://upp.sourceforge .net/www$uppweb$vssw ing$en-us.html

Definitely worth a look and a trial although, for my taste, too "smart
and aggressive" in the use of C++.
RAII rules GC.

:-)

Best wishes,
Roland Pibinger

[Joe Seigh]

Goalie_Ca wrote:

I have been reading (or at least googling) about the potential addition
of optional garbage collection to C++0x. There are numerous myths and
whatnot with very little detailed information.

Will this work be library based or language based and will it be based
on that of managed C++? Then of course there are the finer technical
questions raised (especially due to pointer abuse). Is a GC for C++
just a pipe dream or is there a lot of work in the committee to realise
it.

Part of the problem is there are different forms of GC. Even for tracing
GC there are enough differences that being able to plug in at the library
level might be a little problematic. Whatever solution they pick is not
likely to be neutral as far as the alternative solutions are concerned.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

[Jerry Coffin]

In article <11************ *********@y41g2 000cwy.googlegr oups.com>,
go******@gmail. com says...

I have been reading (or at least googling) about the potential addition
of optional garbage collection to C++0x. There are numerous myths and
whatnot with very little detailed information.

Will this work be library based or language based and will it be based
on that of managed C++? Then of course there are the finer technical
questions raised (especially due to pointer abuse). Is a GC for C++
just a pipe dream or is there a lot of work in the committee to realise
it.

There were a couple of lengthy threads about this in
comp.lang.c++.m oderated. See:

http://tinyurl.com/s57fq

and:

http://tinyurl.com/p5op2

For starters. When I said lengthy, I wasn't kidding though -- reading
through all this will take considerable time (and this thread will
probably echo many of the same arguments).

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Goalie_Ca]

Thanks for those threads. I can see that in general people are divided
at every level on how to approach this problem. To me, the outsider, it
appears that it will not likely make this revision although there is
clearly support for having one included.
Jerry Coffin wrote:

In article <11************ *********@y41g2 000cwy.googlegr oups.com>,
go******@gmail. com says...

I have been reading (or at least googling) about the potential addition
of optional garbage collection to C++0x. There are numerous myths and
whatnot with very little detailed information.

Will this work be library based or language based and will it be based
on that of managed C++? Then of course there are the finer technical
questions raised (especially due to pointer abuse). Is a GC for C++
just a pipe dream or is there a lot of work in the committee to realise
it.

There were a couple of lengthy threads about this in
comp.lang.c++.m oderated. See:

http://tinyurl.com/s57fq

and:

http://tinyurl.com/p5op2

For starters. When I said lengthy, I wasn't kidding though -- reading
through all this will take considerable time (and this thread will
probably echo many of the same arguments).

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Ron House]

Goalie_Ca wrote:

Thanks for those threads. I can see that in general people are divided
at every level on how to approach this problem. To me, the outsider, it
appears that it will not likely make this revision although there is
clearly support for having one included.

My question is a simple one: how do we combine destructors with GC?
Destructors do not become superfluous just because one usage for them
does. Closing files and shutting down other resources in a timely manner
becomes hard when object termination occurs at an indeterminate time. Is
there a way to do this that is sufficiently practical and efficient to
raise no major objections if put into a standard? It is one thing for an
add-on to do it, as we use or not use the add-on to our own liking; but
a standard is another matter.

--
Ron House ho***@usq.edu.a u
http://www.sci.usq.edu.au/staff/house

[Jerry Coffin]

In article <44************ **@usq.edu.au>, ho***@usq.edu.a u says...

Goalie_Ca wrote:

Thanks for those threads. I can see that in general people are divided
at every level on how to approach this problem. To me, the outsider, it
appears that it will not likely make this revision although there is
clearly support for having one included.

My question is a simple one: how do we combine destructors with GC?

One of the threads I previously cited was titled "Reconcilin g Garbage
Collection with Deterministic Finalization". Even with little or no
knowledge of the subject matter, the mere fact that the thread went
on for well over 300 posts tends to show that nobody has a really
solid answer for that.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Alf P. Steinbach]

* Ron House:

Goalie_Ca wrote:

Thanks for those threads. I can see that in general people are divided
at every level on how to approach this problem. To me, the outsider, it
appears that it will not likely make this revision although there is
clearly support for having one included.

My question is a simple one: how do we combine destructors with GC?
Destructors do not become superfluous just because one usage for them
does. Closing files and shutting down other resources in a timely manner
becomes hard when object termination occurs at an indeterminate time. Is
there a way to do this that is sufficiently practical and efficient to
raise no major objections if put into a standard? It is one thing for an
add-on to do it, as we use or not use the add-on to our own liking; but
a standard is another matter.

It's very simple: object destruction is not memory reclamation, and
memory reclamation is not object destruction.

The job of a garbage collector is solely to reclaim memory.

If an object has a non-trivial destructor, one with possible side
effects, then that object cannot be automatically destroyed by a garbage
collector in order to reclaim memory, because then the garbage collector
would intrude in the arena of program logic and correctness.

Thus, a C++ garbage collector compatible with the current standard can
reclaim a region of memory only when:

A. There are no live references to the region (circular references
are not live), and

B. All remaining objects in the region have trivial destructors.

The case where there are no remaining objects in the region (i.e. all
have been destroyed) might seem to be of no practical advantage, but it
is if ::operator delete, rather than deallocating at once, just invokes
object destruction and marks the memory for later automatic reclamation,
which can proceed e.g. when the program's later waiting for user input.

This reduces garbage collection in C++ to an /optimization/ and /memory
leak slurper/, not affecting correctness except to the degree it slurps.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?