Re: Garbage Collection in C
- From: Richard <rgrdev@xxxxxxxxx>
- Date: Tue, 17 Oct 2006 14:38:50 +0200
jacob navia <jacob@xxxxxxxxxxxxxxxx> writes:
Richard wrote:
jacob navia <jacob@xxxxxxxxxxxxxxxx> writes:
SM Ryan wrote:Garbage Collection is the invention of the Devil.
"Bart" <bart.kowalski@xxxxxxxxx> wrote:
# Besides there's more to resource management than malloc/free. Open
# files, handles, connections, matched calls to some APIs. Those all have
# the same inherent problems that memory allocation has. So why a GC
# specifically to deal with just one problem? I suspect that, for C
Some collectors support an operation called finalisation. You can
attach a procedure to a block which is called when the block becomes
garbage. For example, you can attach a file closer to a file object.
# programmers who would want something like this, just writing a few
C++
# wrappers that do some magic in constructors/destructors would probably
# be a lot less painful than your GC.
Shows how twisted things have become. OO became big with Smalltalk
that include garbage collection. C++ didn't have garbage collection
and it was soon discoverred that OO programs generated a lot of
heap memory and freeing those was a major pain. So destructors were
invented to move all this freeing into the object class instead of
the code using the object. This created a new problem in ensuring
the destructor was called at the appropriate time; this gets hard
with throw chains, gotos, long jumps, etc. All this complication was
added because garbage collection was unavailable.
Garbage collection + finalisation allows you everything destructors
do with fewer restrictions in the language and less work by
programmers.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
JUSTICE!
Justice is dead.
EXACTLY.
It is amazing how deep the implications of this go. For instance, it
has been argued that you need constructors/destructors to support
operator overloading in C, since operator overloading needs to destroy
intermediate objects in expressions:
c = (a+b)/(a-b);
when '+' is overloaded, it must create a temporary object. This is
possible using the GC, since you are sure the GC will find the
unneeded object.
It encourages lax design & programming styles.
I hated it in java and I would hate it in C/C++.
We made do with centralised pool allocation/deallocation libraries
and
careful matching of alloc/dealloc for years.
Maybe you enlighten us?
It is the second time you mention this "pool libraries" for ressource
management.
I did? First time I thought, anyway. However you want them to look.
There are laws : if you call them to allocate, you call them to
deallocate. The difference being that during program development you can
log/track accesses and discover the dangling pointers relatively
quickly : one of the main reasons for any level for abstraction. if your
system maintains a pool of runtime objects, allocate them from a
centralised, controlled pool.
Dont get me wrong : its not "very" easy. But then neither is good C programming
or good "any" programming for that
Nothing magic.
.
- References:
- Re: Garbage Collection in C
- From: Bart
- Re: Garbage Collection in C
- From: SM Ryan
- Re: Garbage Collection in C
- From: jacob navia
- Re: Garbage Collection in C
- From: Richard
- Re: Garbage Collection in C
- From: jacob navia
- Re: Garbage Collection in C
- Prev by Date: Re: how can I get warning ?
- Next by Date: implementation of a shell
- Previous by thread: Re: Garbage Collection in C
- Next by thread: Re: Garbage Collection in C
- Index(es):
Relevant Pages
|