SGCL - Garbage Collector for C++

[James Kanze]

std::list<>
or boost::intrusive::list<>
or struct node { smart_pointer<node> next; };
or explicit destruction as Alberto described
or allocation from a pool which is all deallocated together
or garbage collection.

All have their advantages and disadvantages. Personally I'm
happy with std::list 99% of the time. I'm actually quite
curious to know what sort of applications or users use garbage
collection in C++, but I fear that it's the sort of discussion
that can deteriorate....

Not really. There are those of us who are paid to produce
working code as inexpensively as possible. Garbage collection
saves some work in some specific cases (which do occur fairly
frequently, even if they don't represent the majority of dynamic
allocations), so we use it. Not doing so would be
irresponsible, from a professional point of view---something
like using <generic.h> instead of templates.

Naturally, of course:

-- objects with value semantics shouldn't be allocated
dynamically to begin with, so garbage collection won't
affect them,

-- even more obviously, the same thing holds for RAII
mangagers,

-- and generally, entity objects should manage their own
lifetimes---although using garbage collection here does
improve type safety, and allows catching some errors
(dangling pointers).

But there will usually be a few odd objects which don't fit into
one of the above categories, and garbage collection means one
less thing to code when using them (and the detection of
dangling pointers for entity objects isn't to be sneezed at if
you need robustness).

 

[Ioannis Vranos]

SGCL is precise, parallel garbage collection library for C++ (at this
time for Windows 32/64 only). SGCL is free software published under
University of Illinois/NCSA Open Source License.

Get it at:
http://sourceforge.net/projects/sgcl/

Regards
Sebastian Nibisz

Sounds like interesting stuff for anyone who wants to use GC in his/her
applications.

The thread shouldn't turn out to the flame "Do we need garbage
collection"? Anyone that can afford it in his/her applications and wants
to, he/she may use it.

 

[Ioannis Vranos]

> SGCL is precise, parallel garbage collection library for C++ (at this
> time for Windows 32/64 only). SGCL is free software published under
> University of Illinois/NCSA Open Source License.
>
> Get it at:
> http://sourceforge.net/projects/sgcl/
>
> Regards
> Sebastian Nibisz

Sounds like interesting stuff for anyone who wants to use GC in his/her
applications.

The thread shouldn't turn out to the flame "Do we need garbage
collection"? Anyone that can afford it in his/her applications and wants
to, he/she may use it.

 

[Alf P. Steinbach]

* James Kanze:

You're kidding us, right?

Eric was obviously being facious with his suggestion, since it
obviously wouldn't work; I can't imagine anyone not spotting the
problem immediately. The trick about shared_ptr, here, of
course, is that you don't see the recursion, so you may not
realize that you have the same problem until someone explicitly
asks what will happen.

It's really pretty rare that you can recurse 1000000 times
without the stack overflowing.

Huh?


Cheers,

- Alf

 

[Phil Endecott]

You're kidding us, right?

James, that's pretty rude. I know this is usenet but I'd really
appreciate if if you could moderate the way you express yourself. I am
not "kidding you" when I say that I did not spot this problem, which is
why I asked "Why?". I have learnt something new and interesting this
evening. Why you had to chime in with that patronising phrase is beyond me.

Goodbye.

 

[Sam]

It's funny.

It's true. If you do not have the skills and the know-how to keep track of
your own objects, and manage their lifetime, you have no business writing
mission-critical, business software.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBHx1dux9p3GYHlUOIRAsG0AJ9jyQycVNKccijiGxu+wtSXfYZ3pQCfYtcN
eALnun9Sn1DJK+2aUAlLpt0=
=jUjy
-----END PGP SIGNATURE-----

 

[Sam]

Ok. What if there is a cyclical list?

Use your brain, and add two lines of code to the above fragment, making it
work for cyclical lists.

No, I'm not going to show you how to do it. I'm not sure you'll be able to
understand it.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBHx1f8x9p3GYHlUOIRAgtHAJ9XsfYsIvZ4pQ8W4t4Kx6DXxkTDOwCeLBAg
JXRwFrr2SpQBU4RR0SSAWjU=
=vSvG
-----END PGP SIGNATURE-----

 

[Sam]

.

Smart pointers. We all know that boost::shared_ptr is the
answer to all questions concerning pointers. So just replace
all of the pointers with boost::shared_ptr< node >.

No, please, not this horrible, stinking monstrosity called "Boost". The
other day I actually had the misfortune of looking how shared_ptr is
implemented, and nearly lost my lunch. Utterly clueless, brainless design.. I
ended up coding my own version of shared_ptr, and benchmarked it 15% faster
than Boost's disgusting code.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBHx1jVx9p3GYHlUOIRAjm1AJ9SRrSeh4p1oAkO7AThiHBTGKqnqgCeIVVf
TA4+3NMo2v+s9DNiM0Z3d6w=
=ppNd
-----END PGP SIGNATURE-----

 

[Sebastian Nibisz]

I am impressed by your intelligence.

 

[Sam]

I am impressed by your intelligence.

You should be. You can't even manage the task of quoting the message you're
replying to, so that others actually may have a hint as to what in blazes
you're yammering about.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBHx2ikx9p3GYHlUOIRAls5AJ9tENSCTFk2gJcMhcw6xSblXxn9PACfUcYj
MH1+Wpay/btH5+bKpq6HVG8=
=JOuP
-----END PGP SIGNATURE-----

 

[Jeff Schwab]

The parent must know the child.

Sorry, I meant why not use a standard container to manage the nodes'
lifetimes? The slist mentioned elsewhere on this thread was a
reasonable suggestion, if std::list is too heavy.

 

[Jeff Schwab]

* James Kanze:

Huh?

I'm not sure it's obvious until you're been looking at it for a few
minutes, but given a program like the following:

#include <tr1/memory>

using std::tr1::shared_ptr;

struct node {
shared_ptr<node> next;
};

int main() {
shared_ptr<node> root(new node);
shared_ptr<node> n(root);

for (int x = 0; x < 1000000; ++x) {
n = n->next = shared_ptr<node>(new node);
}
}

When the "root" shared_ptr goes out of scope, the first node's reference
count goes to zero. root's destructor therefore deletes the first node,
causing the destructor of root->next to be invoked. That destructor
sees the reference count of the second node become zero, and so deletes
the second node, causing root->next->next to be invoked. And so on...

A better approach, IMHO, would be to let a factory allocate the nodes,
preferably as elements of a std::list<node>. The factory's destructor
(the list's, really) can make sure the memory is freed.

 

[Alf P. Steinbach]

* Jeff Schwab:

I'm not sure it's obvious until you're been looking at it for a few
minutes, but given a program like the following:

#include <tr1/memory>

using std::tr1::shared_ptr;

struct node {
shared_ptr<node> next;
};

int main() {
shared_ptr<node> root(new node);
shared_ptr<node> n(root);

for (int x = 0; x < 1000000; ++x) {
n = n->next = shared_ptr<node>(new node);
}
}

When the "root" shared_ptr goes out of scope, the first node's reference
count goes to zero. root's destructor therefore deletes the first node,
causing the destructor of root->next to be invoked. That destructor
sees the reference count of the second node become zero, and so deletes
the second node, causing root->next->next to be invoked. And so on...

Thanks. I didn't see that. Blind on both eyes!

A better approach, IMHO, would be to let a factory allocate the nodes,
preferably as elements of a std::list<node>. The factory's destructor
(the list's, really) can make sure the memory is freed.

Yup.


Cheers,

- Alf

 

[James Kanze]

It's true. If you do not have the skills and the know-how to
keep track of your own objects, and manage their lifetime, you
have no business writing mission-critical, business software.

And if you intentionally reject the use of a labor saving
device, and do something by hand which can easily be automated,
you're being professionally irresponsible.

 

[James Kanze]

No, please, not this horrible, stinking monstrosity called
"Boost". The other day I actually had the misfortune of
looking how shared_ptr is implemented, and nearly lost my
lunch. Utterly clueless, brainless design. I ended up coding
my own version of shared_ptr, and benchmarked it 15% faster
than Boost's disgusting code.

Hmmm. Apparently some one else who just doesn't understand, and
missed the whole point. Mainly that any smart pointer here will
cause a core dump.

FWIW: in the limited contexts where reference counted pointers
are appropriate, I also use my own. Mainly because I wrote it
long before boost::shared_ptr existed; any advantages it
provides aren't worth the added effort of reinventing the wheel.
But since I do have it, and it is both safer and faster than
boost::shared_ptr for reference counted memory management, I
continue to use it.

Reinventing the wheel, of course, isn't professional; a
professional uses all of the available tools to develop the most
robust software at the lowest price. (Which, of course, means
using garbage collection when it's available and when it's the
appropriate solution---it's a tool, just like any other.)

 

[Nick Keighley]

* Sebastian Nibisz peremptorily fired off this memo:

Ridiculous.

why?

<snip>

 

[James Kanze]

I'm not sure it's obvious until you're been looking at it for
a few minutes,

It depends on context. Given the above snippet of code, it's
not at all obvious that there is a recursion, and I expect it
would slip through most code reviews. Given the fact that this
code appeared as a response to an ironical suggestion to use
recursion, one might be stimulated to think about it, and
recognize the fact. Given that someone had already said "stack
overflow", I'm rather surprised that Alf missed it---he doesn't
usually miss these sort of things.

[...]

A better approach, IMHO, would be to let a factory allocate
the nodes, preferably as elements of a std::list<node>. The
factory's destructor (the list's, really) can make sure the
memory is freed.

There are several possible approches that work well. The one
that requires the least explicit coding on the part of the
developer is garbage collection, which was, I presume, the
intent of the person who first posted this example.

IMHO, the real point here is that unless you're using garbage
collection, different situations require different solutions.
That means additional analysis and coding. Not necessarily a
lot, but each little bit adds up.

 

[James Kanze]

James, that's pretty rude.

I'm sorry, but it's frustrating. Somewhat upthread, someone
said "recursion", doubtlessly ironically, since I do presume
that everyone would realize thatexplicitly recursing 1000000
times was a bad idea. Given the fact that the use of shared_ptr
was suggested in that context, it seems obviously just an
extention of the irony to me---let's hide the recursion.

Without this context, frankly, I don't think many people would
spot the problem in code review. Given the context, however, I
do find it very surprising that people whom I know to be
competent do not see the problem immediately. It makes the
irony somewhat ineffective (although it does strengthen the
argument against unthinking use of shared_ptr). Which is, of
course, frustrating to those of us who are trying to use it.

I know this is usenet but I'd really appreciate if if you
could moderate the way you express yourself. I am not
"kidding you" when I say that I did not spot this problem,
which is why I asked "Why?". I have learnt something new and
interesting this evening. Why you had to chime in with that
patronising phrase is beyond me.

Because people not realizing the problem, in context, spoils the
rhetorical effect of the irony. Sorry. But as soon as Erik
mentionned recursion, it occured to me that I could "hide" it in
a shared_ptr, and that since shared_ptr was often suggested as
an alternative to garbage collection. Then you and Alf go and
spoil the effect (and I know both of you to be extremely
competent programmers) by missing the irony.

 

[Sam]

And if you intentionally reject the use of a labor saving
device, and do something by hand which can easily be automated,
you're being professionally irresponsible.

And you'll be even more professionally irresponsible if you use a so-called
"labor saving device" as merely a crutch to support your own lack of
experience and know-how, rather than taking the time, learning, and
educating yourself on how to do it right in the first place, instead of
relying on mis-designed spaghetti code to pull you nuts out of the fire.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBHx/Ymx9p3GYHlUOIRApqCAJ4tMV17P9o45Zf2twszmk6I0B1iyQCfQ1xL
HG05+JfSQ42GtWN2rRo08VE=
=pnfB
-----END PGP SIGNATURE-----

 

[Sam]

Hmmm. Apparently some one else who just doesn't understand, and
missed the whole point. Mainly that any smart pointer here will
cause a core dump.

Apparently someone else here who just doesn't understand that the problem
here is not with using a smart pointer, but with mis-using it.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBHx/aGx9p3GYHlUOIRApiPAJ9IIT6pltYja1bEbYY/O2apz+7A4ACdEFfW
TPCG1kbgjD0VdeVUi7qtcyY=
=/B+g
-----END PGP SIGNATURE-----