Garbage collection in C++

15 views
Skip to first unread message

pushpa...@gmail.com

unread,
Nov 15, 2008, 10:57:00 AM11/15/08
to
Hi all,

Is garbage collection possible in C++. It doesn't come as part of
language support. Is there any specific reason for the same due to the
way the language is designed. Or it is discouraged due to
some specific reason. If someone can give inputs on the same, it will
be of great help.

Regards,
Pushpa

Chris M. Thomasson

unread,
Nov 15, 2008, 11:32:29 AM11/15/08
to
<pushpa...@gmail.com> wrote in message
news:22b430aa-4990-4dcf...@a29g2000pra.googlegroups.com...

> Hi all,
>
> Is garbage collection possible in C++.

Sure:

http://www.hpl.hp.com/personal/Hans_Boehm/gc


> It doesn't come as part of
> language support. Is there any specific reason for the same due to the
> way the language is designed. Or it is discouraged due to
> some specific reason. If someone can give inputs on the same, it will
> be of great help.

C++ is a low-level systems language, IMVHO, that's no place for a GC to
be...

Bharath

unread,
Nov 15, 2008, 12:03:54 PM11/15/08
to
On Nov 15, 10:32 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> <pushpakul...@gmail.com> wrote in message

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

- bharath

Juha Nieminen

unread,
Nov 15, 2008, 12:21:06 PM11/15/08
to

I have absolutely no experience in third-party garbage collectors for
C++. What I have always wondered, though, is how those can handle a
situation like:

int* foo()
{
int* table = new int[100];
return table+40;
}

The pointer to the beginning of the allocated array dies when foo()
terminates, but a pointer to one of its elements lives beyond the scope
of foo(). This pointer may be used in the calling code. A garbage
collector would have to:

1) Know that there's still a live pointer pointing to (an element
inside) the array, and thus it cannot destroy it yet.

2) Know to delete the array properly (ie. from the original pointer
pointing to the beginning of the array, rather than the one which lived
longer than that) when that returned pointer dies and the GC runs.

I suppose they have figured out these problems. I'm just wondering how.

Pete Becker

unread,
Nov 15, 2008, 12:36:42 PM11/15/08
to
On 2008-11-15 12:21:06 -0500, Juha Nieminen <nos...@thanks.invalid> said:

>
> I have absolutely no experience in third-party garbage collectors for
> C++. What I have always wondered, though, is how those can handle a
> situation like:
>
> int* foo()
> {
> int* table = new int[100];
> return table+40;
> }
>
> The pointer to the beginning of the allocated array dies when foo()
> terminates, but a pointer to one of its elements lives beyond the scope
> of foo(). This pointer may be used in the calling code. A garbage
> collector would have to:
>
> 1) Know that there's still a live pointer pointing to (an element
> inside) the array, and thus it cannot destroy it yet.
>
> 2) Know to delete the array properly (ie. from the original pointer
> pointing to the beginning of the array, rather than the one which lived
> longer than that) when that returned pointer dies and the GC runs.
>
> I suppose they have figured out these problems. I'm just wondering how.

It's just a bit of bookkeeping. When the array is allocated the
collector makes notes about the size of the allocated block and where
it begins. The returned pointer points into the allocated block, so the
block is still live.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Joe Smith

unread,
Nov 15, 2008, 1:44:20 PM11/15/08
to

<pushpa...@gmail.com> wrote in message
news:22b430aa-4990-4dcf...@a29g2000pra.googlegroups.com...

The C++ standardization commitee is working with some garbage collection
related proposals,
although no official garbage collection mechanism will be included in C++0x.
It is not yet clear
if the auxillary proposal to make it easier to support garbage collection
via third party libraries
will be approved for C++0x or not.

Pete Becker

unread,
Nov 15, 2008, 2:56:15 PM11/15/08
to

It's quite clear, since it was approved at the September meeting. <g>
Search for "safely derived pointer" in the current working draft.

Joe Smith

unread,
Nov 15, 2008, 3:53:31 PM11/15/08
to

"Pete Becker" <pe...@versatilecoding.com> wrote in message
news:2008111514561516807-pete@versatilecodingcom...

> On 2008-11-15 13:44:20 -0500, "Joe Smith" <unknown...@hotmail.com>
> said:
>> The C++ standardization commitee is working with some garbage collection
>> related proposals,
>> although no official garbage collection mechanism will be included in
>> C++0x. It is not yet clear
>> if the auxillary proposal to make it easier to support garbage collection
>> via third party libraries
>> will be approved for C++0x or not.
>
> It's quite clear, since it was approved at the September meeting. <g>
> Search for "safely derived pointer" in the current working draft.
>
Roger that, I should have been more clear that it was not clear to me
if the auxillary proposal was included. I'm trying to follow things, but
I am not reading every posted paper, so I may well miss things.

Chris M. Thomasson

unread,
Nov 15, 2008, 5:22:08 PM11/15/08
to
"Chris M. Thomasson" <n...@spam.invalid> wrote in message
news:7OCTk.31$m74...@newsfe24.iad...

C++ is nice because it allows the user to apply just enough of its features
to get the job done. You can use C++ for kernel programming; just not all of
it...

;^D

James Kanze

unread,
Nov 15, 2008, 7:18:40 PM11/15/08
to
On Nov 15, 4:57 pm, pushpakul...@gmail.com wrote:

> Is garbage collection possible in C++.

Yes and no. There are, in fact, a few constructs which could
break it, and there are potential compiler optimizations which
could prevent it from being used.. In practice, the language
constructs are recognized as poor programming practice, and
something to be avoided, regardless, and compilers don't do
optimizations which would break it, and in fact, it is more or
less widely used; see
http://www.hpl.hp.com/personal/Hans_Boehm/gc/.

> It doesn't come as part of language support. Is there any
> specific reason for the same due to the way the language is
> designed. Or it is discouraged due to some specific reason. If
> someone can give inputs on the same, it will be of great help.

More history than any other reasons. It's readily available,
and works, and is being used by a number of people.

--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze

unread,
Nov 15, 2008, 7:20:41 PM11/15/08
to
On Nov 15, 5:32 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> <pushpakul...@gmail.com> wrote in message

> news:22b430aa-4990-4dcf...@a29g2000pra.googlegroups.com...

> > Is garbage collection possible in C++.

> Sure:

> http://www.hpl.hp.com/personal/Hans_Boehm/gc

> > It doesn't come as part of language support. Is there any
> > specific reason for the same due to the way the language is
> > designed. Or it is discouraged due to some specific reason.
> > If someone can give inputs on the same, it will be of great
> > help.

> C++ is a low-level systems language, IMVHO, that's no place
> for a GC to be...

C++ is a multi-paradigm language, usable in many contexts. If
you're writing kernel code, a garbage collector certainly has no
place; nor do exceptions, for that matter. And if you're
implementing a garbage collector, obviously, you can't use it.
But for most application programs, it's stupid not to.

George Kettleborough

unread,
Nov 16, 2008, 2:38:11 AM11/16/08
to

A related question if I may: Is garbage collection necessary if the
programmer follows a strict RAII design ie. only allocating and
deallocating resources in constructors and destructors? Is garbage
collection just to enable you to program more like Java ie. creating
objects on the heap by using new everywhere? What is the advantage of this?

Java also has the finally block, and I understand this won't be
implemented in C++(0x) any time soon because it's not necessary with
RAII. Can garbage collection in C++ work to the same extent as it does
in Java without the finally block?

--
George Kettleborough

Ian Collins

unread,
Nov 16, 2008, 2:43:08 AM11/16/08
to
George Kettleborough wrote:
> On 15/11/08 15:57, pushpa...@gmail.com wrote:
>> Hi all,
>>
>> Is garbage collection possible in C++. It doesn't come as part of
>> language support. Is there any specific reason for the same due to the
>> way the language is designed. Or it is discouraged due to
>> some specific reason. If someone can give inputs on the same, it will
>> be of great help.
>>
>> Regards,
>> Pushpa
>
> A related question if I may: Is garbage collection necessary if the
> programmer follows a strict RAII design ie. only allocating and
> deallocating resources in constructors and destructors? Is garbage
> collection just to enable you to program more like Java ie. creating
> objects on the heap by using new everywhere? What is the advantage of this?
>
GC and RAII are orthogonal concepts.

> Java also has the finally block, and I understand this won't be
> implemented in C++(0x) any time soon because it's not necessary with
> RAII. Can garbage collection in C++ work to the same extent as it does
> in Java without the finally block?
>

Yes.

--
Ian Collins

James Kanze

unread,
Nov 16, 2008, 4:43:15 AM11/16/08
to
On Nov 16, 8:38 am, George Kettleborough
<g.kettleboro...@member.fsf.org> wrote:

> On 15/11/08 15:57, pushpakul...@gmail.com wrote:

> > Is garbage collection possible in C++. It doesn't come as
> > part of language support. Is there any specific reason for
> > the same due to the way the language is designed. Or it is
> > discouraged due to some specific reason. If someone can give
> > inputs on the same, it will be of great help.

> A related question if I may: Is garbage collection necessary


> if the programmer follows a strict RAII design ie. only
> allocating and deallocating resources in constructors and
> destructors?

It rarely makes sense to allocate memory in constructors and
deallocate in destructors. If that's what you're doing, it's
generally preferable to use an object directly, with no dynamic
allocation. There are exceptions, of course, but they're a lot
less frequent than people make out. The main motivation for
using dynamic allocation is precisely because the lifetime of
the object must be arbitrary, and doesn't fit any pre-defined
pattern.

> Is garbage collection just to enable you to program more like
> Java ie. creating objects on the heap by using new everywhere?
> What is the advantage of this?

At the lowest level, garbage collection has two major effects:
it allows memory which can no longer be accessed to be reused
(without programmer intervention), and it forbids memory which
can still be accessed from being reused. The first results in
less work for the programmer in a number of specific instances;
it isn't the panacea that some Java proponents would have us
believe, but every little bit helps. The second results in more
robust programs; the memory for one object can't be reused for
another object due to a premature delete. (Premature delete is
a bug that can be exploited to break security, so you definitly
want garbage collection for this reason if your program connects
directly to the Internet.)

> Java also has the finally block, and I understand this won't
> be implemented in C++(0x) any time soon because it's not
> necessary with RAII. Can garbage collection in C++ work to the
> same extent as it does in Java without the finally block?

What does garbage collection have to do with the finally block?
For that matter, at the level garbage collection works, what is
the difference between a finally block and the destructor of a
local object?

George Kettleborough

unread,
Nov 16, 2008, 5:17:10 AM11/16/08
to
On 16/11/08 09:43, James Kanze wrote:
> On Nov 16, 8:38 am, George Kettleborough
> <g.kettleboro...@member.fsf.org> wrote:
>> On 15/11/08 15:57, pushpakul...@gmail.com wrote:
>
>>> Is garbage collection possible in C++. It doesn't come as
>>> part of language support. Is there any specific reason for
>>> the same due to the way the language is designed. Or it is
>>> discouraged due to some specific reason. If someone can give
>>> inputs on the same, it will be of great help.
>
>> A related question if I may: Is garbage collection necessary
>> if the programmer follows a strict RAII design ie. only
>> allocating and deallocating resources in constructors and
>> destructors?
>
> It rarely makes sense to allocate memory in constructors and
> deallocate in destructors. If that's what you're doing, it's
> generally preferable to use an object directly, with no dynamic
> allocation. There are exceptions, of course, but they're a lot
> less frequent than people make out. The main motivation for
> using dynamic allocation is precisely because the lifetime of
> the object must be arbitrary, and doesn't fit any pre-defined
> pattern.

How would you implement something like a vector without dynamically
allocated memory? I thought dynamically allocated memory was used
because the amount of memory needed can only be decided at run time.

>> Is garbage collection just to enable you to program more like
>> Java ie. creating objects on the heap by using new everywhere?
>> What is the advantage of this?
>
> At the lowest level, garbage collection has two major effects:
> it allows memory which can no longer be accessed to be reused
> (without programmer intervention), and it forbids memory which
> can still be accessed from being reused. The first results in
> less work for the programmer in a number of specific instances;
> it isn't the panacea that some Java proponents would have us
> believe, but every little bit helps. The second results in more
> robust programs; the memory for one object can't be reused for
> another object due to a premature delete. (Premature delete is
> a bug that can be exploited to break security, so you definitly
> want garbage collection for this reason if your program connects
> directly to the Internet.)

I suppose what I don't get is why you would ever want to create objects
on the stack. It's something you can't do in Java, and it's much quicker
to create them on the stack plus they get destructed automatically when
the go out of scope.

>> Java also has the finally block, and I understand this won't
>> be implemented in C++(0x) any time soon because it's not
>> necessary with RAII. Can garbage collection in C++ work to the
>> same extent as it does in Java without the finally block?
>
> What does garbage collection have to do with the finally block?
> For that matter, at the level garbage collection works, what is
> the difference between a finally block and the destructor of a
> local object?

Well, if you are using new in a try block, and an exception is thrown,
C++ will guarantee the destruction of the pointer and anything else on
the stack but it won't call delete for what you allocated there. I
thought the finally block was to "clean up" any resources you allocated
in the try block, something that isn't necessary if you don't
dynamically allocate resources in there (but instead in the constructors
of objects create there, which are guaranteed to be destroyed).

Maybe I have got this all wrong and I am confusing myself, forgive me
because I'm only just beginning to really learn C++!

--
George Kettleborough

Erik Wikström

unread,
Nov 16, 2008, 6:36:10 AM11/16/08
to

Yes, vectors (and other containers) generally needs dynamic allocations
since you do not know how much memory they will need when they are
created (and you might not have enough space on the stack). But for
these kinds of things memory management is easy since you know when you
need to free the memory (when the container dies). The problem is when
you need to create an object in one place and then pass on ownership to
somewhere else (which in turn might pass on ownership).

>>> Java also has the finally block, and I understand this won't
>>> be implemented in C++(0x) any time soon because it's not
>>> necessary with RAII. Can garbage collection in C++ work to the
>>> same extent as it does in Java without the finally block?
>>
>> What does garbage collection have to do with the finally block?
>> For that matter, at the level garbage collection works, what is
>> the difference between a finally block and the destructor of a
>> local object?
>
> Well, if you are using new in a try block, and an exception is thrown,
> C++ will guarantee the destruction of the pointer and anything else on
> the stack but it won't call delete for what you allocated there. I
> thought the finally block was to "clean up" any resources you allocated
> in the try block, something that isn't necessary if you don't
> dynamically allocate resources in there (but instead in the constructors
> of objects create there, which are guaranteed to be destroyed).

For those kinds of situations you can use auto_ptr or some other smart
pointer which will take care of freeing the allocated memory when they
go out of scope (such as when an exception is thrown). What you can not
do without finally is to free other resources, such as opened files,
unless you build a smart fstream or use guard-classes (can't remember if
that is the correct term). Of course, if the fstream is on the stack you
do not have to worry.

--
Erik Wikström

Juha Nieminen

unread,
Nov 16, 2008, 7:06:03 AM11/16/08
to
James Kanze wrote:
> It rarely makes sense to allocate memory in constructors and
> deallocate in destructors. If that's what you're doing, it's
> generally preferable to use an object directly, with no dynamic
> allocation.

Just because the only place where the memory is deallocated is inside
the destructor, that doesn't mean the memory is *always* deallocated
when the destructor is called. Think about smart pointers and other
similar classes (such as eg. some implementation of std::string which
implements copy-on-write).

Besides, if the object allocates a variable amount of memory, then
allocation and destruction is obviously necessary regardless of how you
use the object.

Juha Nieminen

unread,
Nov 16, 2008, 7:24:37 AM11/16/08
to
George Kettleborough wrote:
> A related question if I may: Is garbage collection necessary if the
> programmer follows a strict RAII design ie. only allocating and
> deallocating resources in constructors and destructors? Is garbage
> collection just to enable you to program more like Java ie. creating
> objects on the heap by using new everywhere? What is the advantage of this?

In my previous job I worked for over 5 years in an extensive C++
project, and in my current job I have done so for over 1.5 years.
Although counting lines of code is not really a perfect measurement of
the amount of work done, and I haven't measured exactly how much code I
have written in total in these two jobs, I wouldn't be surprised if it
was well over 100k LOC. Many of the programs deal with dynamically
allocated memory in rather complex ways.

I have from time to time checked for memory leaks in all my programs
with profilers. How many memory leaks have I had in all these years in
all my C++ programs? Zero. Not even once have I had a single memory leak
in any of my code. During these tests I have found many memory leaks in
third-party libraries (which I had to then fix myself), but none in my
own code.

Also I don't remember even once having accessed freed memory. I have
had a few cases where I have accessed allocated memory out of boundaries
(usually because of an off-by-1 mistake), but even those have been less
than a dozen (mostly in the earlier years), and caught rather quickly.

I really haven't ever felt the need for a GC engine in my work. Could
a GC engine have made my job easier in a few cases? Maybe. I can't say
for sure. At most it could have perhaps saved a bit of writing work, but
not increased the correctness of my code in any way. C++ makes it quite
easy to write safe code when you follow some simple rules.

> Java also has the finally block, and I understand this won't be
> implemented in C++(0x) any time soon because it's not necessary with
> RAII.

I must admit I don't have too much Java programming experience, but if
I'm not completely mistaken, finally-blocks can be used in Java, for
example, to do things like this (in pseudo-java):

void foo()
{
try
{
infile = open_file_here;
perform_lots_of_complicated_stuff_which_might_throw;
}
finally
{
close(infile);
}
}

Of course in situations like this there just is no need for a
'finally' block in C++, as the same effect can be achieved almost
automatically:

void foo()
{
std::istream infile(whatever);
perform_lots_of_complicated_stuff_which_might_throw;

// the stream will be automatically closed when foo() is exited
// without having to do anything special to achieve that.
}

Sam

unread,
Nov 16, 2008, 9:54:07 AM11/16/08
to
George Kettleborough writes:

> On 15/11/08 15:57, pushpa...@gmail.com wrote:
>> Hi all,
>>
>> Is garbage collection possible in C++. It doesn't come as part of
>> language support. Is there any specific reason for the same due to the
>> way the language is designed. Or it is discouraged due to
>> some specific reason. If someone can give inputs on the same, it will
>> be of great help.
>>
>> Regards,
>> Pushpa
>
> A related question if I may: Is garbage collection necessary

I'll stop right here. The answer is, obviously, "no", insofar as C++ is
concerned.

The regular posts here about garbage collection in C++ typically come from
newbie programmers who haven't acquired sufficient discipline to keep track
of their own objects. So they seek for a security blanket called "garbage
collection", so they don't have to worry about it, and can proceed to churn
out their spaghetti code without worry, just like they do in Java.

Occasionally some of them stumble across one of several "garbage collection
for C++" libraries, that float out there, and think they've hit paydirt.
Unfortunately, they fail to realize that there are fundamental differences
between C++ and Java, and no "garbage collection" library is going to solve
it.

> Is garbage collection just to enable you to program more like Java ie.
> creating objects on the heap by using new everywhere?

Yes. And not caring about proper class design, and structure. The "C++ for
dummies" approach.

> RAII. Can garbage collection in C++ work to the same extent as it does
> in Java without the finally block?

No. Garbage collection in C++ will not work to the same extent, but for
other reasons.


Juha Nieminen

unread,
Nov 16, 2008, 1:18:20 PM11/16/08
to
Sam wrote:
>> Is garbage collection just to enable you to program more like Java ie.
>> creating objects on the heap by using new everywhere?
>
> Yes. And not caring about proper class design, and structure. The "C++
> for dummies" approach.

Sometimes I get the impression that garbage collection actually causes
people to write *less* modular and more imperative programs. GC doesn't
really encourage encapsulation and modularity.

Sure, you might not get a (permanent) memory leak when you have GC and
you can freely allocate and toss anything you like, but I wonder if this
kind of "irresponsible" programming style doesn't naturally lead to less
modular, less encapsulated programs which are more akin to spaghetti code.

Keith H Duggar

unread,
Nov 16, 2008, 1:36:34 PM11/16/08
to
On Nov 15, 7:20 pm, James Kanze <james.ka...@gmail.com> wrote:
> On Nov 15, 5:32 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > C++ is a low-level systems language, IMVHO, that's no place
> > for a GC to be...
>
> C++ is a multi-paradigm language, usable in many contexts. If
> you're writing kernel code, a garbage collector certainly has no
> place; nor do exceptions, for that matter. And if you're
> implementing a garbage collector, obviously, you can't use it.
> But for most application programs, it's stupid not to.

RAII, RRID, STL containers, automatic variables, value-based design,
and other software design patterns have served exceptionally well in
eliminating both the need and the want for GC in my work.

Furthermore almost every memory management problem I remember finding
recently that would have gone unnoticed in a GC environment was not
only
a resource management problem but was also a logical or design flaw
that
was much better found than swept under the GC rug.

Finally, the deterministic design patterns we employ to eliminate
memory
management problems also apply directly to other scare resources such
as
ports, handles, connections, locks, etc. The same cannot be said for
GC.

How does the above make me stupid for not using GC?

KHD

Keith H Duggar

unread,
Nov 16, 2008, 1:54:11 PM11/16/08
to

My experience echos Juha's almost exactly and I entirely agree
with his conclusion. Futhermore, the determinstic design patterns
that C++ supports help one manage /any/ scarce resource; they are
not limited primarily to memory as GC is. Finally and ironically,
GC can sweep design errors under the rug actually reducing the
semantic correctness of your code rather than improving it.

KHD

hurcan solter

unread,
Nov 16, 2008, 5:46:30 PM11/16/08
to
although it is not strictly necessary , it has its uses with
concurrent programming
it may get really confusing the manage the lifetime of objects when
multiple threads
accessing them ,deleting an object when another thread making use of
it may cause you
headaches(e.g lock-free data structures). although there are solutions
like thread-safe reference counting or hazard pointers they are either
complex or steep on performance and their use are not widespread. GC
may relieve you there.

Hurcan Solter

James Kanze

unread,
Nov 17, 2008, 4:01:27 AM11/17/08
to
On Nov 16, 11:17 am, George Kettleborough

That's certainly one possible reason. It doesn't affect
application code too often, however, because it's already
handled by things like std::vector. If you're implementing
something like the standard library, my comments probably don't
apply. But I doubt that that's the case for most of us.

> >> Is garbage collection just to enable you to program more
> >> like Java ie. creating objects on the heap by using new
> >> everywhere? What is the advantage of this?

> > At the lowest level, garbage collection has two major
> > effects: it allows memory which can no longer be accessed to
> > be reused (without programmer intervention), and it forbids
> > memory which can still be accessed from being reused. The
> > first results in less work for the programmer in a number of
> > specific instances; it isn't the panacea that some Java
> > proponents would have us believe, but every little bit
> > helps. The second results in more robust programs; the
> > memory for one object can't be reused for another object due
> > to a premature delete. (Premature delete is a bug that can
> > be exploited to break security, so you definitly want
> > garbage collection for this reason if your program connects
> > directly to the Internet.)

> I suppose what I don't get is why you would ever want to
> create objects on the stack. It's something you can't do in
> Java, and it's much quicker to create them on the stack plus
> they get destructed automatically when the go out of scope.

I'm not sure I understand what you're saying. You seem to be
contradicting yourself; I suspect that you left out a word
somewhere, but I'm not sure where.

Anyway, unlike Java, C++ has full support for value types, and
you should use them whenever appropriate. In practice, most
objects will be on the stack.

> >> Java also has the finally block, and I understand this
> >> won't be implemented in C++(0x) any time soon because it's
> >> not necessary with RAII. Can garbage collection in C++ work
> >> to the same extent as it does in Java without the finally
> >> block?

> > What does garbage collection have to do with the finally
> > block? For that matter, at the level garbage collection
> > works, what is the difference between a finally block and
> > the destructor of a local object?

> Well, if you are using new in a try block, and an exception is
> thrown, C++ will guarantee the destruction of the pointer and
> anything else on the stack but it won't call delete for what
> you allocated there. I thought the finally block was to "clean
> up" any resources you allocated in the try block, something
> that isn't necessary if you don't dynamically allocate
> resources in there (but instead in the constructors of objects
> create there, which are guaranteed to be destroyed).

The finally block is there to do any actions that must be
performed, period. Just because you have garbage collection
doesn't mean that the could be other actions which need to be
performed.

In C++, destructors of on stack objects (RAII) do the same job.
They require a bit more coding to use in isolated cases, but in
general cases (which seem to prevail), they ensure that the
"clean-up" code is implemented with the code which causes it to
be required, and make it much more difficult for the client
programmer to forget it.

--
James Kanze (GABI Software) email:james...@gmail.com

Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze

unread,
Nov 17, 2008, 4:10:03 AM11/17/08
to
On Nov 16, 1:06 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> James Kanze wrote:
> > It rarely makes sense to allocate memory in constructors and
> > deallocate in destructors. If that's what you're doing,
> > it's generally preferable to use an object directly, with no
> > dynamic allocation.

> Just because the only place where the memory is deallocated is
> inside the destructor, that doesn't mean the memory is
> *always* deallocated when the destructor is called. Think
> about smart pointers and other similar classes (such as eg.
> some implementation of std::string which implements
> copy-on-write).

But the only thing forcing the delete into a smart pointer buys
you is confuscation? The main reason for using dynamic memory
at the application level (implementing std::Vector is obviously
a different situation) is because you need arbitrary lifetime.
The object's lifetime ends in response to some external event.
The handler for that event does the delete.

> Besides, if the object allocates a variable amount of memory,
> then allocation and destruction is obviously necessary
> regardless of how you use the object.

If you're talking about things like vector or map, they're
already written, so they're not my problem. If you're talking
about dynamically types objects, it's true that this sometimes
leads to dynamic allocation even if the object logically should
have block scope. I've not found the case to be that frequent,
but it certainly occurs. In such cases, std::auto_ptr is your
friend, and the delete will be called by the destructor of the
std::auto_ptr. Cases where a normal user would write a delete
in a destructor are fairly rare, however (although the
compilation firewall idiom would be an obvious exception).

--
James Kanze (GABI Software) email:james...@gmail.com

Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze

unread,
Nov 17, 2008, 4:18:09 AM11/17/08
to
On Nov 16, 1:24 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> George Kettleborough wrote:
> > A related question if I may: Is garbage collection necessary
> > if the programmer follows a strict RAII design ie. only
> > allocating and deallocating resources in constructors and
> > destructors? Is garbage collection just to enable you to
> > program more like Java ie. creating objects on the heap by
> > using new everywhere? What is the advantage of this?

> In my previous job I worked for over 5 years in an extensive
> C++ project, and in my current job I have done so for over 1.5
> years. Although counting lines of code is not really a
> perfect measurement of the amount of work done, and I haven't
> measured exactly how much code I have written in total in
> these two jobs, I wouldn't be surprised if it was well over
> 100k LOC. Many of the programs deal with dynamically allocated
> memory in rather complex ways.

> I have from time to time checked for memory leaks in all my
> programs with profilers. How many memory leaks have I had in
> all these years in all my C++ programs? Zero. Not even once
> have I had a single memory leak in any of my code. During
> these tests I have found many memory leaks in third-party
> libraries (which I had to then fix myself), but none in my own
> code.

So how is this different from C? Obviously, you can write C++
code which doesn't leak memory. Just as obviously, you can
write C code which doesn't leak memory. It's just a question of
the effort involved.

> Also I don't remember even once having accessed freed memory.
> I have had a few cases where I have accessed allocated memory
> out of boundaries (usually because of an off-by-1 mistake),
> but even those have been less than a dozen (mostly in the
> earlier years), and caught rather quickly.

The classical C error: strcpy( malloc( strlen( s ) ), s ):-)?
(Back when I was working in C, if someone came to me because
their code was crashing in strange ways, this was the first
thing I'd look for.)

> I really haven't ever felt the need for a GC engine in my
> work. Could a GC engine have made my job easier in a few
> cases? Maybe. I can't say for sure. At most it could have
> perhaps saved a bit of writing work, but not increased the
> correctness of my code in any way. C++ makes it quite easy to
> write safe code when you follow some simple rules.

Yes and no. C++ certainly provides a number of tools which can
be used to improve safety. It doesn't require their use,
however, and I've seen a lot of programmers which don't use them
systematically. And of course, human beings being what they
are, regardless of the tools or the process, mistakes will
occasionally creap in.

James Kanze

unread,
Nov 17, 2008, 4:23:59 AM11/17/08
to
On Nov 16, 3:54 pm, Sam <s...@email-scan.com> wrote:
> George Kettleborough writes:
> > On 15/11/08 15:57, pushpakul...@gmail.com wrote:

> >> Is garbage collection possible in C++. It doesn't come as
> >> part of language support. Is there any specific reason for
> >> the same due to the way the language is designed. Or it is
> >> discouraged due to some specific reason. If someone can
> >> give inputs on the same, it will be of great help.

> > A related question if I may: Is garbage collection necessary

> I'll stop right here. The answer is, obviously, "no", insofar
> as C++ is concerned.

It's not necessary, no. For that matter, classes aren't
necessary either. Garbage collection is just a tool: it reduces
programmer workload, and increases the security of the resulting
code.

> The regular posts here about garbage collection in C++
> typically come from newbie programmers who haven't acquired
> sufficient discipline to keep track of their own objects.

Yah. Newbies with 20 years of C++ experience. Newbies who
unlike you actually know what they're doing. (FWIW, one of the
proponents of garbage collection in the C++ standards committee
is Bjarne Stroustrup. And he's got even more C++ experience
than I do.)

If I were in your place, I wouldn't talk about newbies. You've
consistently shown a lack of understanding of even the most
basic issues in your own postings.

> So they seek for a security blanket called "garbage
> collection", so they don't have to worry about it, and can
> proceed to churn out their spaghetti code without worry, just
> like they do in Java.

That is, of course, the most obvious bullshit I've ever seen.
There are cases where garbage collection isn't appropriate, and
cases where it is necessary. Both are relatively rare; most of
the time, it will save some programmer effort, and result in
cleaner code, but only to a limited degree.

James Kanze

unread,
Nov 17, 2008, 4:25:47 AM11/17/08
to
On Nov 16, 7:18 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> Sam wrote:
> >> Is garbage collection just to enable you to program more
> >> like Java ie. creating objects on the heap by using new
> >> everywhere?

> > Yes. And not caring about proper class design, and
> > structure. The "C++ for dummies" approach.

> Sometimes I get the impression that garbage collection
> actually causes people to write *less* modular and more
> imperative programs. GC doesn't really encourage encapsulation
> and modularity.

Garbage collection doesn't "encourage" anything. It's just a
tool. To be used when appropriate. I use it whenever I can,
and find that it results in less lines of code and more robust
and maintainable code.

James Kanze

unread,
Nov 17, 2008, 4:28:28 AM11/17/08
to
On Nov 16, 11:46 pm, hurcan solter <hsol...@gmail.com> wrote:
> although it is not strictly necessary , it has its uses with
> concurrent programming it may get really confusing the manage
> the lifetime of objects when multiple threads

Attention! Garbage collection does NOT manage the lifetime of
objects. It only manages memory. It's generally useful in
multithreaded environments for performance reasons, but it
doesn't address issues as to which thread has the right to
access which objects when. That problem is completely
orthogonal to how you manage memory (unless you're writing the
memory management code yourself, of course).

Sam

unread,
Nov 17, 2008, 7:08:06 AM11/17/08
to
James Kanze writes:

> On Nov 16, 3:54 pm, Sam <s...@email-scan.com> wrote:
>> George Kettleborough writes:
>> > On 15/11/08 15:57, pushpakul...@gmail.com wrote:
>
>> >> Is garbage collection possible in C++. It doesn't come as
>> >> part of language support. Is there any specific reason for
>> >> the same due to the way the language is designed. Or it is
>> >> discouraged due to some specific reason. If someone can
>> >> give inputs on the same, it will be of great help.
>
>> > A related question if I may: Is garbage collection necessary
>
>> I'll stop right here. The answer is, obviously, "no", insofar
>> as C++ is concerned.
>
> It's not necessary, no. For that matter, classes aren't
> necessary either. Garbage collection is just a tool: it reduces

So is a shovel. It's also a tool. There are situations where you can use a
shovel to do something useful. C++ isn't one of them.

>> The regular posts here about garbage collection in C++
>> typically come from newbie programmers who haven't acquired
>> sufficient discipline to keep track of their own objects.
>
> Yah. Newbies with 20 years of C++ experience. Newbies who

Don't get snippy with me, young man. I outrank you by a few years.

> unlike you actually know what they're doing. (FWIW, one of the
> proponents of garbage collection in the C++ standards committee
> is Bjarne Stroustrup. And he's got even more C++ experience
> than I do.)

A quick search finds no evidence that he is a "proponent" of garbage
collection. He discusses the subject, but not from a position of advocacy,
and actually argues that there are better techniques available, in C++, than
garbage collection.


James Kanze

unread,
Nov 17, 2008, 9:03:59 AM11/17/08
to
On Nov 17, 1:08 pm, Sam <s...@email-scan.com> wrote:
> James Kanze writes:
> > On Nov 16, 3:54 pm, Sam <s...@email-scan.com> wrote:
> >> George Kettleborough writes:
> >> > On 15/11/08 15:57, pushpakul...@gmail.com wrote:

> >> >> Is garbage collection possible in C++. It doesn't come
> >> >> as part of language support. Is there any specific
> >> >> reason for the same due to the way the language is
> >> >> designed. Or it is discouraged due to some specific
> >> >> reason. If someone can give inputs on the same, it will
> >> >> be of great help.

> >> > A related question if I may: Is garbage collection necessary

> >> I'll stop right here. The answer is, obviously, "no",
> >> insofar as C++ is concerned.

> > It's not necessary, no. For that matter, classes aren't
> > necessary either. Garbage collection is just a tool: it
> > reduces
>
> So is a shovel. It's also a tool. There are situations where
> you can use a shovel to do something useful. C++ isn't one of
> them.

You might try a better analogy. Shovels aren't used in
programming in general (although there are more than a few
programs that I would like to bury). Garbage collection is
useful in C++, and in fact, is actively being used by a number
of programmers.

> >> The regular posts here about garbage collection in C++
> >> typically come from newbie programmers who haven't acquired
> >> sufficient discipline to keep track of their own objects.

> > Yah. Newbies with 20 years of C++ experience. Newbies who

> Don't get snippy with me, young man. I outrank you by a few
> years.

If you did, you'd be retired. (The first machine I ever
programmed was an IBM 1401. Beat that if you can:-).)

> > unlike you actually know what they're doing. (FWIW, one of the
> > proponents of garbage collection in the C++ standards committee
> > is Bjarne Stroustrup. And he's got even more C++ experience
> > than I do.)

> A quick search finds no evidence that he is a "proponent" of
> garbage collection.

Have you checked in the discussions on the mail reflectors of
the standardization group? He's more interested in other
aspects, but has expressed himself in favor of garbage
collection on several occasions.

Note that this is an evolution in his position (due, I suspect,
to an evolution in garbage collection technolgy); before 1990,
he doubtlessly could have added it without really asking anyone.
But the technology available before 1990 is a far cry from what
is available today.

> He discusses the subject, but not from a position of advocacy,
> and actually argues that there are better techniques
> available, in C++, than garbage collection.

There are certainly better techniques for some things. For
others, not necessarily. Anything which reduces the amount of
code I have to write myself is a good thing; there are enough
real problems in my applications that I don't have to
artificially create extra work just to keep me busy. And like
all techniques, it can easily be abused, but the fact that
something can be abused isn't a reason for not including it in
C++.

The only real problem garbage collection has is that it has been
presented as a panacea by some (not all) Java proponents; I've
actually been told that you couldn't have memory leaks in Java,
because of garbage collection (at the same time that Sun was
admitting to serious memory leaks in Swing). If you expect
garbage collection to solve every problem, you're going to be
disappointed. But that's not a problem with garbage collection;
that's a problem with your expectations. (And it's not really
unlike many of the postings here on the subject of smart
pointers.)

Chris M. Thomasson

unread,
Nov 17, 2008, 12:14:24 PM11/17/08
to

"James Kanze" <james...@gmail.com> wrote in message
news:39609efb-1a8d-4a37...@w1g2000prk.googlegroups.com...

On Nov 16, 3:54 pm, Sam <s...@email-scan.com> wrote:
[...]

> > So they seek for a security blanket called "garbage
> > collection", so they don't have to worry about it, and can
> > proceed to churn out their spaghetti code without worry, just
> > like they do in Java.

> That is, of course, the most obvious bullshit I've ever seen.
> There are cases where garbage collection isn't appropriate, and
> cases where it is necessary.

Humm.. Can you give an example or two of a scenario in which a GC is
absolutely required/necessary? For some reason, I can't seem to think of one
off the top of my head. What am I missing? Perhaps I misunderstand your use
of the word "necessary"...


> Both are relatively rare; most of
> the time, it will save some programmer effort, and result in
> cleaner code, but only to a limited degree.

I have seen a couple of cases in which a GC covered up more than a "simple
memory leak". Simple example... What if the memory leak was entangled in a
logic error that sometimes caused weird execution results. If the programmer
was alerted to the memory leak, perhaps he/she could have noticed the logic
error as well. Of course, this is highly contrived case. However, it can
occur.

One bad thing about GC is that it sometimes pulls programmers into a false
sense of security, and they end up creating a sloppy design. This is NOT the
fault of the GC, but of the lazy programmer. One can create efficiently
engineered programs _and_ use a GC at the same time.

Juha Nieminen

unread,
Nov 17, 2008, 2:23:28 PM11/17/08
to
James Kanze wrote:
> So how is this different from C?

C++ makes it much easier to write safe code, and following the
principles which make code safer is much simpler. In other words, there
are lots of situations where you simply don't have to worry about
leakages in any way in C++, while you do have to worry about then in C
because C doesn't help automatizing.

For example, if I instantiate an std::istream at the beginning of a
function, I just don't have to care about closing that file handle at
all. The std::istream object does it automatically for me completely
regardless of where, when and how the function in question is exited,
and regardless of how many exit points it might have. This is not the
case in C, where you always have to be very careful to not to leak (a
file handle in this case).

A garbage collection engine would certainly be much more useful when
programming in C because in C it requires a lot more work to write safe
code, and a GC engine can help a lot in that. In C++ it's my personal
feeling that a GC engine is not *that* useful.

(Of course regardless of having a GC, you can still leak file handles.)

Juha Nieminen

unread,
Nov 17, 2008, 2:29:51 PM11/17/08
to
James Kanze wrote:
>> Sometimes I get the impression that garbage collection
>> actually causes people to write *less* modular and more
>> imperative programs. GC doesn't really encourage encapsulation
>> and modularity.
>
> Garbage collection doesn't "encourage" anything.

I tend to disagree. Garbage collection encourages writing
"irresponsible" code. By this I mean that since there's no need for
objects to have (memory handling) responsibilities, it easily leads to
the programmer not creating such objects at all, which in turn leads to
a more imperative style of programming, rather than a more modular style.

Some people may (and do) argue that this is a good thing, but I
wouldn't be so sure. Granted, you won't leak memory (well, not
permanently at least), but your code may suffer from spaghettification
just because you were too lazy to actually write some modules rather
than writing "raw" code.

And no, this doesn't mean *all* programmers using a GC'd language
suffer from this.

> It's just a tool. To be used when appropriate.

Well, if it would be a *choice*, then it wouldn't be so bad. There are
languages, however, where you are force-fed and you have no choice.

Chris M. Thomasson

unread,
Nov 17, 2008, 2:34:08 PM11/17/08
to
"Juha Nieminen" <nos...@thanks.invalid> wrote in message
news:QwjUk.173$Ge4...@read4.inet.fi...

> James Kanze wrote:
>> So how is this different from C?
>
> C++ makes it much easier to write safe code, and following the
> principles which make code safer is much simpler. In other words, there
> are lots of situations where you simply don't have to worry about
> leakages in any way in C++, while you do have to worry about then in C
> because C doesn't help automatizing.
>
> For example, if I instantiate an std::istream at the beginning of a
> function, I just don't have to care about closing that file handle at
> all. The std::istream object does it automatically for me completely
> regardless of where, when and how the function in question is exited,
> and regardless of how many exit points it might have. This is not the
> case in C, where you always have to be very careful to not to leak (a
> file handle in this case).

Closing a file handle in a dtor can be _very_ problematic indeed; read here:

http://groups.google.com/group/comp.lang.c++/browse_frm/thread/ec97ab562016d016

Chris M. Thomasson

unread,
Nov 17, 2008, 2:37:11 PM11/17/08
to

"Chris M. Thomasson" <n...@spam.invalid> wrote in message
news:lEjUk.7810$Wd1....@newsfe06.iad...

> "Juha Nieminen" <nos...@thanks.invalid> wrote in message
> news:QwjUk.173$Ge4...@read4.inet.fi...
>> James Kanze wrote:
>>> So how is this different from C?
>>
>> C++ makes it much easier to write safe code, and following the
>> principles which make code safer is much simpler. In other words, there
>> are lots of situations where you simply don't have to worry about
>> leakages in any way in C++, while you do have to worry about then in C
>> because C doesn't help automatizing.
>>
>> For example, if I instantiate an std::istream at the beginning of a
>> function, I just don't have to care about closing that file handle at
>> all. The std::istream object does it automatically for me completely
>> regardless of where, when and how the function in question is exited,
>> and regardless of how many exit points it might have. This is not the
>> case in C, where you always have to be very careful to not to leak (a
>> file handle in this case).
>
> Closing a file handle in a dtor can be _very_ problematic indeed; read
> here:
>
> http://groups.google.com/group/comp.lang.c++/browse_frm/thread/ec97ab562016d016
[...]

refer to the file copy problem in following post:

http://groups.google.com/group/comp.lang.c++/msg/78a928139ca349f4

if the system specific internal call to close the file fails in the dtor of
the higher level file object, well, then the shi% will hit the fan;
permanent data loss! Ouch.

:^/

Hans Bos

unread,
Nov 17, 2008, 4:14:15 PM11/17/08
to

"Juha Nieminen" <nos...@thanks.invalid> schreef in bericht
news:PCjUk.174$Ge4...@read4.inet.fi...

> James Kanze wrote:
>>> Sometimes I get the impression that garbage collection
>>> actually causes people to write *less* modular and more
>>> imperative programs. GC doesn't really encourage encapsulation
>>> and modularity.
>>
>> Garbage collection doesn't "encourage" anything.
>
> I tend to disagree. Garbage collection encourages writing
> "irresponsible" code. By this I mean that since there's no need for
> objects to have (memory handling) responsibilities, it easily leads to
> the programmer not creating such objects at all, which in turn leads to
> a more imperative style of programming, rather than a more modular style.

Are saying that people that can't make proper programs using garbage
collection will make good programs without gc?

Sam

unread,
Nov 17, 2008, 6:40:46 PM11/17/08
to
James Kanze writes:

> On Nov 17, 1:08 pm, Sam <s...@email-scan.com> wrote:
>> James Kanze writes:
>> > It's not necessary, no. For that matter, classes aren't
>> > necessary either. Garbage collection is just a tool: it
>> > reduces
>>
>> So is a shovel. It's also a tool. There are situations where
>> you can use a shovel to do something useful. C++ isn't one of
>> them.
>
> You might try a better analogy. Shovels aren't used in
> programming in general (although there are more than a few
> programs that I would like to bury). Garbage collection is
> useful in C++, and in fact, is actively being used by a number
> of programmers.

Garbage collection is as useful for C++ as a fifth leg would be useful to a
dog. A dog with five legs might find some use for the extra one, but most of
the time it would just get in the way.

Some people may find some cockamamie "garbage collection library" useful,
but many more do not. Furthermore, there are also people who also find
intermediate code generators useful too. Specifically ones that swallow some
glob of XML, and spew out robo-generate spaghetti code that does something
else XML-related. It's useful to a small minority, because it allows them to
put their brain in "park", and not bother learning how the stuff should
work. Which leaves them completely helpless if the end result does not work
as expected, since they have no clue how the spaghetti code works, and
what's wrong with it.

>> He discusses the subject, but not from a position of advocacy,
>> and actually argues that there are better techniques
>> available, in C++, than garbage collection.
>
> There are certainly better techniques for some things. For
> others, not necessarily. Anything which reduces the amount of
> code I have to write myself is a good thing; there are enough

There is no such magic wand that one can wave, and make a bunch of code
disappear. Anyone who thinks that is fooling themselves. Garbage
collection-based design results in larger memory requirements, greater
resources, and slower code. That's the tradeoff for not having to bother
with such troublesome tasks as keeping proper track of your objects,
yourself.

But if I wanted to go in that direction, I'd use Java.


Sam

unread,
Nov 17, 2008, 6:42:54 PM11/17/08
to
Hans Bos writes:

> "Juha Nieminen" <nos...@thanks.invalid> schreef in bericht
> news:PCjUk.174$Ge4...@read4.inet.fi...

>> I tend to disagree. Garbage collection encourages writing
>> "irresponsible" code. By this I mean that since there's no need for
>> objects to have (memory handling) responsibilities, it easily leads to
>> the programmer not creating such objects at all, which in turn leads to
>> a more imperative style of programming, rather than a more modular style.
>
> Are saying that people that can't make proper programs using garbage
> collection will make good programs without gc?

No, they won't make any programs at all.

Which is a good thing. But only from a theoretical viewpoint. From a
practical viewpoint, those kinds of people should be encourage to spew out
reams of atrocious code. Some people make a pretty good living cleaning up
these messes.


Keith H Duggar

unread,
Nov 17, 2008, 11:23:22 PM11/17/08
to

Yes. However, garbage collection is /only/ going to reclaim
memory, eventually. It's not going to correct the logical and
potentially far more serious design bugs that leaked memory
in the first place. In fact, garbage collection can and does
hide bugs exactly by allowing access to objects that should
not be accessed thus actually reducing correctness. How do
you respond to this?

The various C++ techniques that of course are familiar to you
for managing memory deterministically not only help one prevent
garbage memory, they also help one properly manage other scare
resources which garbage collection does nothing for. How do you
respond to this? Is it not better to learn the more general more
comprehensive deterministic resource management paradigms that C++
supports? And to apply them uniformly and widely?

> C++ is a multi-paradigm language, usable in many contexts. If
> you're writing kernel code, a garbage collector certainly has
> no place; nor do exceptions, for that matter. And if you're
> implementing a garbage collector, obviously, you can't use it.
> But for most application programs, it's stupid not to.

RAII, RRID, STL containers, automatic variables, value types,


and other software design patterns have served exceptionally

well in eliminating both the need and the want for GC for me.

Furthermore almost every memory management problem I remember

finding recently that would have gone unnoticed with GC in use,
was not only a resource management problem but was also a flaw
in logic or design that was much better found than swept under
the GC rug.

Finally, the deterministic design patterns C++ supports for
memory management also apply directly to other scare resources


such as ports, handles, connections, locks, etc. The same cannot
be said for GC.

In light of the above, why is it "stupid" not to use GC?

KHD

Keith H Duggar

unread,
Nov 17, 2008, 11:57:44 PM11/17/08
to
On Nov 17, 4:28 am, James Kanze <james.ka...@gmail.com> wrote:
> On Nov 16, 11:46 pm, hurcan solter <hsol...@gmail.com> wrote:
>
> > although it is not strictly necessary , it has its uses with
> > concurrent programming it may get really confusing the manage
> > the lifetime of objects when multiple threads
>
> Attention! Garbage collection does NOT manage the lifetime of
> objects. It only manages memory.

Attention! In practice the above is FALSE! If it were correct
there would not have been the rather lengthy discussion recently
in comp.lang.c++.moderated among a few of the world's foremost
C++ experts regarding "zombie" states etc.

http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/c9079ef911de670f/

(Don't be fooled by the topic. It was a Trojan Horse bearing the
gift of GC. For example see the subthread starting with post 63.
If the link fails search for "throwing default constructors".)

When one tries to divorce, in practical terms, the concepts of
object "lifetime" and object "storage" the can opens and spills
worms all over your language model. Since you did not post in
that recent thread I'm not sure what your solution for

"destroyed but not deallocated"

is. If you have one please post it so that Andrei and the like
can employ (or at least research) it.

KHD

James Kanze

unread,
Nov 18, 2008, 5:10:10 AM11/18/08
to
On Nov 17, 8:23 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> James Kanze wrote:

[...]


> A garbage collection engine would certainly be much more
> useful when programming in C because in C it requires a lot
> more work to write safe code, and a GC engine can help a lot
> in that. In C++ it's my personal feeling that a GC engine is
> not *that* useful.

For what definition of "that". It's certainly not as essential
as it is in Java. On the other hand, it fits into the
philosophy of C++, giving the programmer a maximum of tools for
him to choose from, rather than a limited set, predefined by
someone's idea of what is "good".

> (Of course regardless of having a GC, you can still leak file
> handles.)

That's an entirely different issue, which neither GC nor RAII
really address; unlike freeing memory, freeing a file handle can
fail, so you have to do it explicitly, in order to check the
status and handle a possible error. (It's also different
because it affects state outside the program; until you close
the file, other programs can't see what you've written to it.)

James Kanze

unread,
Nov 18, 2008, 5:28:20 AM11/18/08
to
On Nov 18, 5:23 am, Keith H Duggar <dug...@alum.mit.edu> wrote:
> On Nov 17, 4:18 am, James Kanze <james.ka...@gmail.com> wrote:

> > On Nov 16, 1:24 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> > > I really haven't ever felt the need for a GC engine in my
> > > work. Could a GC engine have made my job easier in a few
> > > cases? Maybe. I can't say for sure. At most it could have
> > > perhaps saved a bit of writing work, but not increased the
> > > correctness of my code in any way. C++ makes it quite easy
> > > to write safe code when you follow some simple rules.

> > Yes and no. C++ certainly provides a number of tools which
> > can be used to improve safety. It doesn't require their
> > use, however, and I've seen a lot of programmers which don't
> > use them systematically. And of course, human beings being
> > what they are, regardless of the tools or the process,
> > mistakes will occasionally creap in.

> Yes. However, garbage collection is /only/ going to reclaim
> memory, eventually. It's not going to correct the logical and
> potentially far more serious design bugs that leaked memory in
> the first place.

Woah. If the error is leaked memory, garbage collection may
correct it. Or it may not, depending on whether there is still
a pointer floating around to the memory. (The Java bugs data
base has more than a few cases of memory leaks in it.)

That's not what garbage collection is for. Garbage collection
isn't designed to make an incorrect program correct---I don't
think any tool can guarantee that. Garbage collection (like all
of the other tools I know) is designed to make it easier to
write a correct program. It also makes the effects of some
errors (dangling pointers) less critical.

> In fact, garbage collection can and does hide bugs exactly by
> allowing access to objects that should not be accessed thus
> actually reducing correctness. How do you respond to this?

How should I respond to some wild and erroneous claim? In fact,
garbage collection helps to detect bugs; it is necessary in
order to effectively detect precisely the bug you describe.
Without garbage collection, it's undefined behavior; with
garbagea collection, it's a testable condition.

> The various C++ techniques that of course are familiar to you
> for managing memory deterministically not only help one
> prevent garbage memory,

They also require additional work.

> they also help one properly manage other scare resources which
> garbage collection does nothing for. How do you respond to
> this?

Different "resources" have different constraints. Garbage
collection is fine for memory. RAII often (usually?) works well
for locks and such. You need explicit, programmer controlled
management for resources such as open files, where "release" can
fail. One size doesn't fit all.

Memory is, of course, a very special resource, since it is used
by *all* objects. Only a very small subset of objects use any
other resource (except CPU, but that one pretty much takes care
of itself). So if memory is automatically managed, only a very
small subset of objects need explicit handling, rather than all
of them. Which means less work for the programmer.

> Is it not better to learn the more general more comprehensive
> deterministic resource management paradigms that C++ supports?
> And to apply them uniformly and widely?

You need to understand many different types of resource
management (and often transaction management in general---the
problem isn't just resources) if you want to write correct code.
Garbage collection doesn't dumb down the language, so that
idiots can use it. It just means that an intelligent programmer
has less lines of code to write. No more, no less.

> > C++ is a multi-paradigm language, usable in many contexts. If
> > you're writing kernel code, a garbage collector certainly has
> > no place; nor do exceptions, for that matter. And if you're
> > implementing a garbage collector, obviously, you can't use it.
> > But for most application programs, it's stupid not to.

> RAII, RRID, STL containers, automatic variables, value types,
> and other software design patterns have served exceptionally
> well in eliminating both the need and the want for GC for me.

Exactly. You've mentionned a number of very useful tools.
Garbage collection is just one more to add to the list.
Sometimes, it will mean that you need to write less code.

> Furthermore almost every memory management problem I remember
> finding recently that would have gone unnoticed with GC in
> use, was not only a resource management problem but was also a
> flaw in logic or design that was much better found than swept
> under the GC rug.

That's an oxymoron. If it was a memory management problem, then
garbage collection might have solved it (or it might not---if
you leave unused entries in an std::map, garbage collection
isn't going to remove them for you). If it was a flaw in logic
or design, then it's not a memory management problem. And if it
isn't detected by your development process (code review, tests,
etc.), with or without garbage collection, then you have a
serious problem in your development process.

> Finally, the deterministic design patterns C++ supports for
> memory management also apply directly to other scare resources
> such as ports, handles, connections, locks, etc. The same
> cannot be said for GC.

Except that there is no one design pattern that applies equally
to all resources (or other state which must be rolled back).

> In light of the above, why is it "stupid" not to use GC?

Not doing so means more lines of code. If you don't have enough
to do, and your employer is happy to pay you for busy work,
fine. Otherwise, you really should have garbage collection in
your tool kit (supposing other constraints allow it).

James Kanze

unread,
Nov 18, 2008, 5:49:47 AM11/18/08
to
On Nov 17, 8:29 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> James Kanze wrote:
> >> Sometimes I get the impression that garbage collection
> >> actually causes people to write *less* modular and more
> >> imperative programs. GC doesn't really encourage encapsulation
> >> and modularity.

> > Garbage collection doesn't "encourage" anything.

> I tend to disagree.

Sorry, but it's a statement of fact. Garbage collection is just
a tool; a piece of code. It can't encourage or discourage
anything.

At one time, some proponents of garbage collection were trying
to sell it as a silver bullet. Or rather, to sell it as part of
a larger package which was presented as a silver bullet.
Serious programmers, of course, no that silver bullets don't
exist.

> Garbage collection encourages writing "irresponsible" code.

How can some code in your machine encourage anything. You're
attributing motives and characterists of a living being to an
inanimate object. (There's a name for this, but I've forgotten
it. But it's frequent among programmers---how often do you hear
a programmer talk about a "bug" which "crept into" his software,
rather than to say "I made an error"?)

> By this I mean that since there's no need for objects to have
> (memory handling) responsibilities, it easily leads to the
> programmer not creating such objects at all, which in turn
> leads to a more imperative style of programming, rather than a
> more modular style.

Sorry, but I can't follow this at all. Garbage collection
certainly reduces the need for objects dedicated uniquely to
memory management, but how does this relate to whether code is
imperative or not.

For that matter, there are cases where an imperative style is
good. One size doesn't fit all; you need to use the appropriate
technique, among all of those available, to solve each problem.
In practice, garbage collection makes OO (OO in the sense of
using polymorphic objects) easier; polymorphic objects generally
have to be allocated dynamically (supposing the exact type not
known at compile time).

> Some people may (and do) argue that this is a good thing,

What is a good thing?

> but
> I wouldn't be so sure. Granted, you won't leak memory (well,
> not permanently at least),

Where to you get this. Garbage collection doesn't mean that you
won't leak memory. The bug list for Java contains a number of
memory leaks.

> but your code may suffer from spaghettification just because
> you were too lazy to actually write some modules rather than
> writing "raw" code.

> And no, this doesn't mean *all* programmers using a GC'd
> language suffer from this.

Programmers who want to write spaghetti will write spaghetti.
With or without garbage collection. You're not going to claim
that C and C++ encourage readability, I hope. Not with the
preprocessor, pointer arithmetic, and their declaration syntax.

> > It's just a tool. To be used when appropriate.

> Well, if it would be a *choice*, then it wouldn't be so bad.
> There are languages, however, where you are force-fed and you
> have no choice.

We're talking about C++ here. Where the guiding principle is
that the programmer knows best. And the philosophy is to give
him as many different tools as possible, for him to choose what
it best at any given time.

Other languages have other philosophies. In some cases, what
they were trying to force-feed you wasn't actually a bad idea.
(I'm thinking of Eiffel and programming by contract.) But even
then, experience (mine, anyway) shows that it doesn't pay off in
the long run. As the technology (the tools set) becomes more
widely used, we learn more about it, and change our ideas
somewhat about how to use it.

There are doubtlessly applications where garbage collection
shouldn't be used at all. (There are, in fact, applications
where dynamic memory shouldn't be used at all.) And it
certainly isn't the solution for everything. But the fact that
a technology can be misused has never been an argument against
introducing it into C++, provided that it also has advantages
when correctly used.

James Kanze

unread,
Nov 18, 2008, 6:03:41 AM11/18/08
to

:-). Yes. For a long time, C was my job security. Nothing
quite beats pointer arithmetic for spewing out reams of code
that only a guru can maintain, and the implicit declaration of
functions can be pretty cool too.

I'll admit that I don't quite understand this argument with
regards to garbage collection. Bad programmers will be bad
programmers, with or without garbage collection. ("The
determined Real Programmer can write Fortran in any language.")
C++ already offers a lot of useful features for making a mess of
things; globally, I think that in the hands of a good
programmer, garbage collection will result in smaller, easier to
understand programs (that corresponds to my experience, at
least---and I consider myself a good programmer), but I'm sure
that the bad programmers will find original ways to use it to
screw things up as well.

This is, I think, a major point in the philosophy of C++. Some
languages try to limit you to a small subset of programming
constructs, claiming that doing this will ensure maintainable
programs (or sometimes even claiming that it will ensure correct
programs). Of course, each new language in this group disagrees
which constructs, and it never works out in the end---bad
programmers are too clever. C++, on the other hand, takes the
attitude that the programmer is a mature and responsible adult,
and is not totally incompetent. And that you can and should
give him whatever tools he can best make use of, even if he
could abuse them. Or to use a frequent analogy, some languages
won't give you a saw, because you might cut yourself. C++ gives
you a chain saw, a rip saw, a band saw, and a couple of other
types of saws. So you can cut yourself badly if you don't know
what you're doing. But also cut wood, metal, or anything else,
in just about any shape you want. In this regard, garbage
collection is just another type of saw.

James Kanze

unread,
Nov 18, 2008, 6:09:18 AM11/18/08
to
On Nov 18, 12:40 am, Sam <s...@email-scan.com> wrote:
> James Kanze writes:
> > On Nov 17, 1:08 pm, Sam <s...@email-scan.com> wrote:
> >> James Kanze writes:
> >> > It's not necessary, no. For that matter, classes aren't
> >> > necessary either. Garbage collection is just a tool: it
> >> > reduces

> >> So is a shovel. It's also a tool. There are situations
> >> where you can use a shovel to do something useful. C++
> >> isn't one of them.

> > You might try a better analogy. Shovels aren't used in
> > programming in general (although there are more than a few
> > programs that I would like to bury). Garbage collection is
> > useful in C++, and in fact, is actively being used by a
> > number of programmers.

> Garbage collection is as useful for C++ as a fifth leg would
> be useful to a dog. A dog with five legs might find some use
> for the extra one, but most of the time it would just get in
> the way.

Another ridiculous analogy, which doesn't relate to anything.

> Some people may find some cockamamie "garbage collection
> library" useful, but many more do not.

Really. Every one I've talked to who's used the Boehm collector
has found it useful.

> Furthermore, there are also people who also find intermediate
> code generators useful too. Specifically ones that swallow
> some glob of XML, and spew out robo-generate spaghetti code
> that does something else XML-related. It's useful to a small
> minority, because it allows them to put their brain in "park",
> and not bother learning how the stuff should work. Which
> leaves them completely helpless if the end result does not
> work as expected, since they have no clue how the spaghetti
> code works, and what's wrong with it.

In other words, if I need to tokenize input, I should write my
tokenizer by hand, rather than use some regular expression based
tool. If I want to test my application, I should write all of
the boiler plate code by hand, rather than using some test
generator. If I want to run a program consisting of machine
instructions, I should write the machine instructions by hand,
rather than using some compiler and linker.

I think you're being a bit silly. And missing the point. Doing
less work (writing less lines of code, etc.) is good.

> >> He discusses the subject, but not from a position of
> >> advocacy, and actually argues that there are better
> >> techniques available, in C++, than garbage collection.

> > There are certainly better techniques for some things. For
> > others, not necessarily. Anything which reduces the amount
> > of code I have to write myself is a good thing; there are
> > enough

> There is no such magic wand that one can wave, and make a
> bunch of code disappear. Anyone who thinks that is fooling
> themselves. Garbage collection-based design results in larger
> memory requirements, greater resources, and slower code.

Than what? In the cases I've actually seen, garbage collection
does result in increased memory use, sometimes significantly,
and this must be taken into account. (But what is cheaper,
memory, or programmer time.) In most cases, it results in the
program running faster, or appearing to. (But of course, you
could manually optimize the non-garbage collected code to do the
same thing.)

James Kanze

unread,
Nov 18, 2008, 6:20:25 AM11/18/08
to
On Nov 17, 6:14 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> "James Kanze" <james.ka...@gmail.com> wrote in message

> news:39609efb-1a8d-4a37...@w1g2000prk.googlegroups.com...
> On Nov 16, 3:54 pm, Sam <s...@email-scan.com> wrote:
> [...]

> > > So they seek for a security blanket called "garbage
> > > collection", so they don't have to worry about it, and can
> > > proceed to churn out their spaghetti code without worry,
> > > just like they do in Java.
> > That is, of course, the most obvious bullshit I've ever
> > seen. There are cases where garbage collection isn't
> > appropriate, and cases where it is necessary.

> Humm.. Can you give an example or two of a scenario in which a
> GC is absolutely required/necessary?

Off hand, no, but I think Hans Boehm had one.

> For some reason, I can't seem to think of one off the top of
> my head. What am I missing? Perhaps I misunderstand your use
> of the word "necessary"...

Sort of. The statement wasn't meant to be taken as giving any
absolute limits, but rather simply to indicate that there is a
great range. (Of course, if you have limited resources to
develop the code, and garbage collection means you need to write
less lines of code---which it usually does---you could argue
that it is necessary to develop the code within budget.)

> > Both are relatively rare; most of the time, it will save
> > some programmer effort, and result in cleaner code, but only
> > to a limited degree.

> I have seen a couple of cases in which a GC covered up more
> than a "simple memory leak". Simple example... What if the
> memory leak was entangled in a logic error that sometimes
> caused weird execution results. If the programmer was alerted
> to the memory leak, perhaps he/she could have noticed the
> logic error as well. Of course, this is highly contrived case.
> However, it can occur.

Not with any of the organizations I've worked with. In the ones
which took quality seriously, code review and tests would have
detected the error. In the other ones, the leak likely would
have gone undetected.

Dangling pointers are a different issue. Garbage collection
allows reliable detection of dangling pointers to dynamically
allocated memory (but not to local variables); without garbage
collection, you can't detect the case reliably. And dangling
pointers are a known security risk for programs connecting to an
open network.

> One bad thing about GC is that it sometimes pulls programmers
> into a false sense of security,

Garbage collection is just a bunch of code. It doesn't "pull"
programmers in any way. Anthropomorphic analogies really don't
apply; code is not a living being.

> and they end up creating a sloppy design. This is NOT the
> fault of the GC, but of the lazy programmer.

Or the incompetent one. Or the mismanaged one. But programmers
don't need garbage collection to be lazy, incompetent or
mismanaged.

> One can create efficiently engineered programs _and_ use a GC
> at the same time.

Certainly. And that's why it should be an available option, to
be used as appropriate.

Hendrik Schober

unread,
Nov 18, 2008, 3:28:39 AM11/18/08
to
James Kanze wrote:
> On Nov 16, 8:38 am, George Kettleborough
> <g.kettleboro...@member.fsf.org> wrote:
>> On 15/11/08 15:57, pushpakul...@gmail.com wrote:
>
>>> Is garbage collection possible in C++. It doesn't come as
>>> part of language support. Is there any specific reason for
>>> the same due to the way the language is designed. Or it is
>>> discouraged due to some specific reason. If someone can give
>>> inputs on the same, it will be of great help.
>
>> A related question if I may: Is garbage collection necessary
>> if the programmer follows a strict RAII design ie. only
>> allocating and deallocating resources in constructors and
>> destructors?
>
> It rarely makes sense to allocate memory in constructors and
> deallocate in destructors. If that's what you're doing, it's
> generally preferable to use an object directly, with no dynamic
> allocation. [...]

Except that the latter isn't polymorphic.

Schobi

Message has been deleted

James Kanze

unread,
Nov 18, 2008, 7:07:02 AM11/18/08
to
On Nov 18, 5:57 am, Keith H Duggar <dug...@alum.mit.edu> wrote:
> On Nov 17, 4:28 am, James Kanze <james.ka...@gmail.com> wrote:

> > On Nov 16, 11:46 pm, hurcan solter <hsol...@gmail.com> wrote:

> > > although it is not strictly necessary , it has its uses
> > > with concurrent programming it may get really confusing
> > > the manage the lifetime of objects when multiple threads

> > Attention! Garbage collection does NOT manage the lifetime
> > of objects. It only manages memory.

> Attention! In practice the above is FALSE!

Apparently, then, you don't even know what garbage collection
does. Garbage collection manages memory. It does NOT manage
object lifetime. The two are different things (and the C++
standard very decisively keeps them separate).

> If it were correct there would not have been the rather
> lengthy discussion recently in comp.lang.c++.moderated among a
> few of the world's foremost C++ experts regarding "zombie"
> states etc.

> http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thr...

> (Don't be fooled by the topic. It was a Trojan Horse bearing
> the gift of GC. For example see the subthread starting with
> post 63. If the link fails search for "throwing default
> constructors".)

> When one tries to divorce, in practical terms, the concepts of
> object "lifetime" and object "storage" the can opens and
> spills worms all over your language model. Since you did not
> post in that recent thread I'm not sure what your solution for

> "destroyed but not deallocated"

> is. If you have one please post it so that Andrei and the like
> can employ (or at least research) it.

It's not a recent topic, and Andrei and I have discussed it in
newsgroups in the past, and unless his position has radically
changed, we more or less agree.

But I'm not sure what your question is. It's obvious that in
this case, garbage collection is necessary to protect against
and detect using dangling pointers. The idiom works because
with garbage collection, memory management is decoupled from
object lifetime; because even though the object has ceased to
exist, the memory behind it cannot be reused as long as anyone
has a pointer to it.

Sam

unread,
Nov 18, 2008, 7:18:00 AM11/18/08
to
James Kanze writes:

> On Nov 18, 12:40 am, Sam <s...@email-scan.com> wrote:
>
>> Garbage collection is as useful for C++ as a fifth leg would
>> be useful to a dog. A dog with five legs might find some use
>> for the extra one, but most of the time it would just get in
>> the way.
>
> Another ridiculous analogy, which doesn't relate to anything.

Really? What exactly is so ridiculous about it. A dog does just fine having
only four legs. It has no pressing need for a fifth one. If he had one, he'd
probably find some use for it, but most of the time it'll just get in the
way. A perfect analogy for garbage collection.

>> Some people may find some cockamamie "garbage collection
>> library" useful, but many more do not.
>
> Really. Every one I've talked to who's used the Boehm collector
> has found it useful.

You cannot extrapolate such a small sample to the world at large.
Furhtermore -- this is a perfect example:

* Forget about having a proper design. Just start allocating globs, left and
right, and rely on the garbage collector to clean up after you. This is
really a sign of a naive and inexperienced developer.

* There's nothing I like more than my application grinding to a halt, while
the garbage collector scans the heap for pointers.

>> Furthermore, there are also people who also find intermediate
>> code generators useful too. Specifically ones that swallow
>> some glob of XML, and spew out robo-generate spaghetti code
>> that does something else XML-related. It's useful to a small
>> minority, because it allows them to put their brain in "park",
>> and not bother learning how the stuff should work. Which
>> leaves them completely helpless if the end result does not
>> work as expected, since they have no clue how the spaghetti
>> code works, and what's wrong with it.
>
> In other words, if I need to tokenize input, I should write my
> tokenizer by hand, rather than use some regular expression based
> tool. If I want to test my application, I should write all of
> the boiler plate code by hand, rather than using some test
> generator. If I want to run a program consisting of machine
> instructions, I should write the machine instructions by hand,
> rather than using some compiler and linker.

A garbage collector is not a tokenizer and not a compiler. Both of these
tools do what cannot be done efficiently in other ways. There's nothing some
garbage collector does can do that cannot be done using proper design,
methodology, and programming practices. Your argument is that a garbage
collector saves you time from having to do all those pesky things one needs
to do, in order to implement something properly. Well, I suppose, but
sometimes one needs to spend the appropriate amount of time to do things
right. It's an investment well spent.

And, yes, there are certain occasions where a hand-built lexer is better.

>> There is no such magic wand that one can wave, and make a
>> bunch of code disappear. Anyone who thinks that is fooling
>> themselves. Garbage collection-based design results in larger
>> memory requirements, greater resources, and slower code.
>
> Than what?

Than proper C++ code that's designed correctly, by someone who knows what
he's doing.

> In the cases I've actually seen, garbage collection
> does result in increased memory use, sometimes significantly,
> and this must be taken into account. (But what is cheaper,

Indeed. The Sun approach. Throw gobs of memory at the problem, and hope that
it goes away.

Now I understand why people were so amazed when I managed to produce an
XML-database gateway, in C++, that consumed less than a hundred or so
of heap, per process instance. Doing these kinds of things efficiently, with
an eye towards minimizing your footprint, is virtually unknown, these days,
now with all these fancy-shmancy garbage collectors and robocode-spewers
making it "convenient" for most not to actually learn how to do this right.


zr

unread,
Nov 18, 2008, 7:27:38 AM11/18/08
to
On Nov 17, 11:28 am, James Kanze <james.ka...@gmail.com> wrote:
> On Nov 16, 11:46 pm, hurcan solter <hsol...@gmail.com> wrote:
>
> > although it is not strictly necessary , it has its uses with
> > concurrent programming it may get really confusing the manage
> > the lifetime of objects when multiple threads
>
> Attention! Garbage collection does NOT manage the lifetime of
> objects.  It only manages memory.  It's generally useful in
> multithreaded environments for performance reasons, but it
> doesn't address issues as to which thread has the right to
> access which objects when.  That problem is completely
> orthogonal to how you manage memory (unless you're writing the
> memory management code yourself, of course).
>
How can GC improve the performance of a multithreaded application? Can
you show a convincing example?

Matthias Buelow

unread,
Nov 18, 2008, 8:41:42 AM11/18/08
to
Keith H Duggar wrote:

> Yes. However, garbage collection is /only/ going to reclaim
> memory, eventually. It's not going to correct the logical and
> potentially far more serious design bugs that leaked memory
> in the first place.

Yes, GC does not correct any bugs, you're right about that ;). However,
there are many situations where having to do manual deallocation is just
additional work without any benefit. For example, if you're doing a lot
of tree handling, building trees, throwing them away again etc., you
don't really want to traverse the tree to free all the elements if you
throw it away. Much more convenient to simply "forget" the pointer to
the tree and let automatic memory management wipe it up.
(This is a bit relativized if you have a situation where you need to
have destructors run in tree nodes; in general, the concepts of
destructors and GC don't really work well together, and imho,
destructors are rather an ugly add-hoc hack that stems from the lack of
automatic memory management and because of that unfortunately has firmly
established itself in C++...)

Matthias Buelow

unread,
Nov 18, 2008, 8:47:49 AM11/18/08
to
Juha Nieminen wrote:

> By this I mean that since there's no need for
> objects to have (memory handling) responsibilities, it easily leads to
> the programmer not creating such objects at all,

Isn't that a good thing? The best code is the one you don't have to
write. Down with bureaucracy. Creating objects just to keep track of
memory dependencies is... inane?

> which in turn leads to
> a more imperative style of programming, rather than a more modular style.

Imperative programming and modular programming are orthogonal concepts.

Matthias Buelow

unread,
Nov 18, 2008, 9:08:47 AM11/18/08
to
zr wrote:

> How can GC improve the performance of a multithreaded application? Can
> you show a convincing example?

Many of today's programs (OO or not) have a high
allocation(/deallocation) rate. This means that most objects become
garbage quickly. With many GCs, their collection time is a function of
the amount of live data, that is, they don't have to traverse the
garbage at all. This means in total, in such a situation, there's less
work to do than in a manual deallocation scheme, where all the garbage
is being traversed aswell.
I don't know if multithreading is any factor here; with manual schemes,
you have to do synchronization, too.

zr

unread,
Nov 18, 2008, 9:29:03 AM11/18/08
to

But even if in these (rare/common) cases where GC can improve
performance over manual deallocation, isn't there a better solution
which would give better performance than GC? Is performance a real
consideration for adding GC to the language?

Matthias Buelow

unread,
Nov 18, 2008, 9:33:57 AM11/18/08
to
zr wrote:

> But even if in these (rare/common) cases where GC can improve
> performance over manual deallocation, isn't there a better solution
> which would give better performance than GC? Is performance a real
> consideration for adding GC to the language?

No, convenience is. If it increases performance, all the better.

anon

unread,
Nov 18, 2008, 9:35:09 AM11/18/08