SGCL - Garbage Collector for C++

[I V]

You're making no sense.

If you separate the object destruction phase from the memory release
phase, then you must be asserting that you are going to be explicitly
invoking the object destruction phase, at some point, yourself, instead
of relying on the garbage collector on doing that.

GC is typically used with objects where the object destruction phase does
nothing. With these objects, you don't need to invoke the object
destruction phase, implicitly or explicitly, so you can just ignore it
and let the GC deal with the memory release phase. So the problem you're
talking about here doesn't arise.

 

[I V]

That's precisely the point I am making. Garbage collection's only
benefit is to clean up your objects when you can't keep track of their
lifetime, and must rely on the garbage collector to destroy the objects
when they no longer have any strong references. Because if you do have
the discipline to keep track of your objects, and destroy them when
they're no longer needed, you don't need any fscking garbage collector.

But if you don't particularly care when objects are deleted (which, when
the only resource an object uses is memory, you may be right not to care
about), then with a GC you don't need the discipline to keep track of
these objects. Which is good, because my discipline, at any rate, is
finite, and I would like to preserve it for those cases where it matters,
not those cases where it doesn't matter.

 

[Kai-Uwe Bux]

It is a destructor in the C++ sense as in "gets invoked before the
object's memory is released".

Now, that is definitely _not_ a destructor in the C++ sense: according to
[3.8/4] it is possible to release or reuse memory without the destructor
getting invoked before.

That's precisely the point I am making. Garbage collection's only benefit
is to clean up your objects when you can't keep track of their lifetime,
and must rely on the garbage collector to destroy the objects when they no
longer have any strong references. [snip]

Are you sure that garbage collectors for C++ _destroy_ objects that become
unreachable? I was under the impression that they only reclaim the memory
and do not invoke the destructor.


Best

Kai-Uwe Bux

 

[Ian Collins]

GC is typically used with objects where the object destruction phase does
nothing. With these objects, you don't need to invoke the object
destruction phase, implicitly or explicitly, so you can just ignore it
and let the GC deal with the memory release phase. So the problem you're
talking about here doesn't arise.

But how does a user know if an object has to be deleted, or whether it
can be left to the GC?

Languages like Java and JavaScript are unambiguous in this regard,
everything gets mopped up by the GC. The languages design requires GC.
It's the ambiguity with C++ I don't like, especially as C++ provides
language features that make GC an irrelevance.

For my own stuff, I pretty well use some form of smart pointer anywhere
I would have used a raw pointer, so I have no need for any form of GC.

 

[Ioannis Vranos]

Make that "*not* acceptable!

As all computers (from small embedded devices to large mainframes) are
getting more powerful along with their accompanying facilities, the
abstraction in programming will be increasing. Now we have those CLI
compliant GC frameworks (.NET, Mono etc), and I am pretty sure GC will
be common place sometime in the near future. Also we will see more
abstraction facilities, and less trade offs between space and speed. The
same applies for storage medium. For example consider mp3/ogg vs flac.
Now we have "mp3 players" with storage >1 GB.

This flame in this thread, reminds me other silly flames between C and
C++ advocates, with the C ones insisting that they can do whatever they
need without object oriented programming, templates etc.

Personally I think the near future will be with more abstraction (like
more templates, GC) and with less low-level facilities, since space and
run-time will have less importance, because of the more and more
powerful systems.

 

[Jeff Schwab]

That's not a destructor in the C++ sense, it's a finalizer.

It is a destructor in the C++ sense as in "gets invoked before the
object's memory is released".

Now, that is definitely _not_ a destructor in the C++ sense: according to
[3.8/4] it is possible to release or reuse memory without the destructor
getting invoked before.

Or, for that matter, to invoke the destructor without releasing the
memory (as std::vector does on each call to pop_back).

That's precisely the point I am making. Garbage collection's only benefit
is to clean up your objects when you can't keep track of their lifetime,
and must rely on the garbage collector to destroy the objects when they no
longer have any strong references. [snip]

Are you sure that garbage collectors for C++ _destroy_ objects that become
unreachable? I was under the impression that they only reclaim the memory
and do not invoke the destructor.

I am not familiar with the Boehm collector; ref-counted GC (e.g.
shared_ptr) does invoke the destructor. In general, though, I believe
you are correct: The two ideas of destruction and collection are
distinct and separable.

 

[Chris Thomasson]

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/

How does this compare against a virtually zero-overhead PDR algorithm?

 

[Chris Thomasson]

But how does a user know if an object has to be deleted, or whether it
can be left to the GC?

Languages like Java and JavaScript are unambiguous in this regard,
everything gets mopped up by the GC. The languages design requires GC.
It's the ambiguity with C++ I don't like, especially as C++ provides
language features that make GC an irrelevance.

For my own stuff, I pretty well use some form of smart pointer anywhere
I would have used a raw pointer, so I have no need for any form of GC.

Yeah. GC has it's problems... Here is just one of many:

http://groups.google.com/group/comp.programming.threads/browse_frm/thread/5e9357a6fb746e5d

 

[James Kanze]

True, but there's plenty of embedded platforms with POSIX
support where garbage collection, even if available, would be
acceptable.

I presume you mean "wouldn't be acceptable".

The issue is more complex than that. There are definitly
contexts where garbage collection wouldn't be acceptable; there
are even a lot of contexts where dynamic allocation isn't
acceptable. In such contexts, the "Posix" environment, per se,
typically isn't acceptable either, but...

Even critical systems have non critical parts, where both
classical Posix and garbage collection might be acceptable, and
there are systems which provide a Posix interface, or at least
something fairly similar, or possibly just a subset, but which
also provide additional guarantees which make them usable in
even the most critical contexts.

If a platform didn't have threads or sockets, it would an
unlikely candidate for a port of an application that used
them. Even if it was chosen, being libraries with well
documented interfaces, they could be implemented, simulated or
stubbed by any competent developer. You can't make the same
claim for GC!

Can't you? I'm not sure.

The real issue is what you're targetting with your
"portability". If you want to be portable to absolutely
everything, then of course, you can't count on garbage
collection, or Posix, or even 2's complement integers. That
level of portability is rarely relevent outside low level
libraries, however. At the other extreme, most of the places
I've worked lately have pretty much standardized on Solaris on
Sparc. They express the portability concerns differently: they
refuse to migrate to a new platform unless our existing code
base will work on it. The issue of migrating to Linux has
recently been very relevant, and GC is the least of our worries:
the Boehm collector works well on both platforms, although a lot
of the "Posix" functions have subtly different semantics. (And
of course, even under Solaris, the semantics of pthread_exit and
pthread_cancel are different depending on whether you compiled
with g++ or Sun CC.)

 

[James Kanze]

Ian Collins wrote: [...]
As all computers (from small embedded devices to large mainframes) are
getting more powerful along with their accompanying facilities, the
abstraction in programming will be increasing. Now we have those CLI
compliant GC frameworks (.NET, Mono etc), and I am pretty sure GC will
be common place sometime in the near future.

Not "sometime in the near future". Today, it's actually rather
rare for a new development to not use GC. Partially, of course,
because most new developments do use either CLI or are in Java.
But many more serious, large scale developments do use C++ and
the Boehm collector. (In practice, Java doesn't really scale to
large scale developments, and CLI doesn't really work except on
Windows platforms, which aren't appropriate for large scale
developments.)

Also we will see more abstraction facilities, and less trade
offs between space and speed. The same applies for storage
medium.

Yes. In a lot of applications, garbage collection is faster,
but typically, it uses more memory. Given the size of current
memories, this usually isn't an issue (but it could be in some
applications, particularly numeric simulations of large scale
physical phenomena, like weather).

For example consider mp3/ogg vs flac. Now we have "mp3
players" with storage >1 GB.

The question for something like a program used to predict the
weather is: do I use this extra memory to simplify memory
managment (which is already very, very simple, since the only
dynamic allocations are in a couple of very, very big arrays),
or do I use it to increase the density of points I'm plotting.

There are applications for which garbage collection isn't
appropriate. There are others---most business applications, for
example---where it represents a definite gain.

This flame in this thread, reminds me other silly flames
between C and C++ advocates, with the C ones insisting that
they can do whatever they need without object oriented
programming, templates etc.

In some cases, how true. That doesn't seem to be Ian's case,
however.

Personally I think the near future will be with more
abstraction (like more templates, GC) and with less low-level
facilities, since space and run-time will have less
importance, because of the more and more powerful systems.

In the near future, either C++ will support threads and garbage
collection, or it will become a niche language. That's really
independent of technical advantages of one or the other.

Currently, I see a lot of applications which are multithreaded,
but which shouldn't be. Realistically, if garbage collection
were part of the language, I expect that there will be a lot of
applications which use it where it's not appropriate. But just
as realistically, there are applications where one or the other
are appropriate, it's important that the language support them,
and the fact that something can be misused has never been an
argument against having it in the language.

 

[James Kanze]

You're making no sense.

Either you're making no sense, or there's something about C++
you haven't understood.

If you separate the object destruction phase from the memory
release phase,

You don't change much. Currently, operator delete() and the
destructor are two different functions. The only link in the
current situation is that operator delete() will not normally be
called unless the destructor is called, so in a lot of cases,
you end up with destructors you wouldn't otherwise need.

then you must be asserting that you are going to be explicitly
invoking the object destruction phase, at some point,
yourself, instead of relying on the garbage collector on doing
that.

Certainly. The garbage collector never invokes object
destruction. The two things are separate concepts, and as such
should be disassociated.

But if that's what you're going to do, if you are going to be
destroying your objects yourself, then what exactly are you
going to gain by not freeing the memory, right then and there,
instead of leaving it to the garbage collector to free the
memory at some later, indeterminate point?

A lot of objects don't have any real actions which have to be
carried out at the end of their lifetime. By design, in many
cases.

If we compare to Java, of course, garbage collection is much
less fundamental in C++. Our value objects are allocated on the
stack, and copied---since dynamic allocation isn't involved,
garbage collection is completely irrelevant. Entity objects
have a defined lifetime in both languages, and must be
explicitly disposed of (normally via the destructor in C++, and
some specific member function in Java)---the real problem with
them is ensuring that all interested parties are notified. In
such cases, garbage collection can help in debugging---you can
mark the object as invalid, and check the mark any time the
object is used, without any risk that the memory underlying the
object will be reused (and the mark overwritten) as long as
anyone still holds a pointer to the object. But it's purely a
defensive programming issue---in correct code, it shouldn't make
a difference. The fact remains, however, that there are other
types of objects. They're not numerous, but they do exist. In
my code, for example, I make some use of agents---small,
polymorphic objects without any real data (perhaps a pointer to
the object they operate on). Garbage collection is perfect for
them. And in other domains, there are complicated graph
structures---this is where garbage collection shines.

The usual way I've used garbage collection to date is to simply
replace operator new() with a function which calls gc_malloc(), and
operator delete() with one which calls gc_free(). And then
simply drop user defined destructors in classes like string, or
in my agents. It's less code which needs to be written. And
less code is always an improvement.

Bravo! You finally got it.

What do you mean, finally. This has always been a fundamental
concept for any competent programmer.

What you seem to be missing is the "if". In a lot of
applications, that if will usually be false, so the then part of
the sentence doesn't apply. Obviously, you need to do the
analysis to determine if it applies, but you need to do that
anyway, garbage collection or not---you need to know what to put
in the destructor before you write it. The difference when
using garbage collection is that if that analysis shows that
nothing really needs to be done (except memory management),
you're through. You've finished the job. Without garbage
collection, you've still got code to write.

In the contexts I've worked in, I've always had enough code to
write as is, without artificially creating the need to write
more.

If you're going to explicitly destroy the object, then you're
going to free the memory right than and there.

Maybe. You might want to keep it as long as there are pointers
to it, for error checking.

And of course, if you weren't going to explicitly destroy the
object, because disposing of the object had no significant
behavior, then garbage collection is a definite gain.

To stop short before doing that, and leaving it to the garbage
collector, is absolutely demented, and you gain absolutely
nothing from doing that.

You gain robustness, when you need to explicitly dispose of the
object, and a lot less code to write, when you don't.

If you're going to use a garbage collection model,

Garbage collection isn't a model. It's a tool. Maybe that's
where you're having problems with it.

it logically follows that you're postponing object
destruction/finalization until then. Because if you're not --
if you're going to destroy and finalize the object yourself --
then you'll simply free the memory at the same time too,
because by the virtue of invoking the destructor, you are
stating that no references to the object remain, so you can
free the memory right than and there.

Disposing of an object is logically distinct from memory
management. The only constraint is that the object must be
disposed of before the memory is reused. Disposing of an
object---by that I mean explicitly terminating its lifetime,
with observable behavior linked to the end of lifetime---is a
design issue, and must always be addressed, at the design level,
regardless of the tool set used at a lower level. Memory
management is a much lower level issue.

Refusing to do that, and instead choosing to foist a
completely unnecessary garbage collection framework on your
neck, in that situation, is completely and utterly retarded.

And that's precisely why I wrote, right from the start, that
garbage collection is only for those who are too stupid to
manage and keep track of their objects, and their lifetime,
themselves.

Which, of course, is false. No professional, today, would start
a new C++ application without considering garbage collection,
any more than he'd start it without considering templates, or
threads, or any other feature readily available. In many ways,
it's a lot like threads: you use it if it helps produce a
working application in less time, and you don't if it doesn't.
It costs nothing if you don't use it, and if it is appropriate,
using it reduces costs.

Because if they do have enough wits to keep track of their
objects' lifetime, and invoke their destructors at the
appropriate time, they'll just release the memory at the same
time. We even have an operator for doing that. It's called
"delete".

As another example in this thread has shown, it isn't always
that simple.

 

[James Kanze]

And when your app does not have any idle moments, you end up
running out of memory.

No, you end up running the garbage collector at a bad moment.

My own work doesn't involve applications which never have idle
moments, but I can easily imagine two cases:

-- large numeric applications, which only allocate a few large
arrays (everything else is on the stack)---in general, the
garbage collector will never run with these, but garbage
collection may not be appropriate, since it typically
requires more memory (and less time, but not in this case),
and

-- applications doing intensive calculations on graph
structures---garbage collection is a resounding win in terms
of development time for these, but using it will often
require a bit of tuning, explicitly triggering garbage
collection at moments when there are very few elements in
the graph. (Typically, manual allocation run time depends
on the number of allocations and frees, garbage collection
run time depends on the amount of memory allocated when the
collector runs.)

<Splorf>

That actually happened at day job, last week. A tick data app
ran out of memory and crashed, because it kept chewing on the
exchange's tick feed, and had no spare cycles for the Java VM
to run the garbage collector, and release memory held my
objects that were no longer in use.

Unless you've modified the JVM in some way, that simply cannot
happen. When Java runs out of memory, it automatically triggers
garbage collection. It sounds more like your application had a
memory leak. (Note that memory leaks are also possible without
garbage collection. In fact, garbage collection reduces the
risk of memory leaks. Without bringing it down to zero, of
course.)

 

[James Kanze]

But how does a user know if an object has to be deleted, or
whether it can be left to the GC?

Maybe because he knows what the object is used for, and why he
created it in the first place?

Languages like Java and JavaScript are unambiguous in this
regard, everything gets mopped up by the GC. The languages
design requires GC.

Java uses dynamic allocation even for value types. That pretty
much makes garbage collection a necessity, and not just an added
feature to improve programmer productivity.

C++, even with garbage collection, continues to support true
value types, and RAII continues to work as usual.

It's the ambiguity with C++ I don't like, especially as C++
provides language features that make GC an irrelevance.

Not an irrelevance. Less important, but programmer productivity
is never really irrelevant.

For my own stuff, I pretty well use some form of smart pointer
anywhere I would have used a raw pointer, so I have no need
for any form of GC.

I tried that, and gave up with it. It resulted in too many
memory leaks. In my applications, most pointers are used for
navigation, not for ownership. And raw pointers work perfectly
well for navigation.

That doesn't mean that there aren't exceptions. I just finished
working on a large block of code which made extensive use of my
pre-boost shared pointer. But it was a closed system, with very
definite constraints on the dynamic memory (a parse tree, so no
cycles). Also, it represented very low level code, which must
be able to work even in systems where garbage collection isn't
an option---otherwise, garbage collection would have made coding
slightly easier (but only slightly, in this case---since the
shared pointer did work) and probably significantly faster
(but since the parse tree is mainly used in off line
calculations, speed really isn't an issue).

 

[James Kanze]

Java most certainly has destructors. See
java.lang.Object.finalize().

Finalization is a completely separate concept from destruction.
The proposals for garbage collection in C++ also include
finalization, but in addition to, not in lieu of destructors.
The two concepts fulfil completely different roles.

Java has local objects too. But that's going to be your
homework assignment for today.

All objects in Java are allocated dynamically. Java has a few,
special types which are not objects, and which cannot be
allocated dynamically.

It has everything to do with garbage collection.

Only for people who don't understand what garbage collection is
or does, or how C++ works.

Whoooooooosh!!! Right over your head.

It's becoming more and more apparent that you don't really know
either C++ or Java. In both languages, a file descripter is
freed when you close the file. Nothing to do with garbage
collection. Or destructors, really---you need to check the
return code of the close(), and do something if the close fails,
so you really can't defer it to the constructor anyway.

You keep repeating this, but repeating something, over and
over again, does not necessarily make it true.

Well, no one has yet shown the slightest relationship between
the two. In the absense of a relationship, it would seem that
you're the one repeating the same untruth over and over.

 

[James Kanze]

It has nothing to do with a destructor in the C++ sense, and
serves a completely different role.

It is a destructor in the C++ sense as in "gets invoked before
the object's memory is released".

That's not what a destructor is in C++ (and not necessarily
true---typically, it's not true for local variables, nor for
static objects, nor for member variables, for example). A
destructor in C++ is a function which is called at a specific
time, and "deconstructs" an object into raw memory.

If the destructor is called as part of a delete expression, then
operator delete() will be called immediately afterwards, which
may or may not immediately free the memory. (Typically, it will
immediately free the memory, except in some cases where the
delete is called in a different thread than the corresponding
new.)

That's precisely the point I am making.

The problem is that the point you're making is simply false.

Garbage collection's only benefit is to clean up your objects
when you can't keep track of their lifetime, and must rely on
the garbage collector to destroy the objects when they no
longer have any strong references.

That's the first time I've heard that. No one arguing in favor
of garbage collection has presented such an argument.

Rather than inventing idiocies, and then proving them false, you
should try addressing what people are really saying.

 

[James Kanze]

[...]

Are you sure that garbage collectors for C++ _destroy_ objects
that become unreachable? I was under the impression that they
only reclaim the memory and do not invoke the destructor.

That's because you actually know what you're talking about, and
having just imagined some strawman to argue against.

Destructors have no relationship with Java's finalize method.
The closest concept to destructors in Java is a finally block.
There are a few special cases where a finally block works better
than destructors (closing files is an obvious example, where
only the user can know what the appropriate behavior is in case
of an error), but they are IMHO very much the exception---for
something between 90% and 99% of the time, destructors are
preferable.

In most cases (there are a few exceptions), finalization is
really only usable for error detection. (I've written large
applications in Java, and have never used it.)

 

[Ioannis Vranos]

> Java uses dynamic allocation even for value types. That pretty
much makes garbage collection a necessity, and not just an added
feature to improve programmer productivity.

C++, even with garbage collection, continues to support true
value types, and RAII continues to work as usual.

Keep in mind that "Java" is two things. "Java" the language+ Java
Virtual Machine. They could provide the JVM with a common API for many
languages, as MS does with .NET.

In "VC++ .NET" case we have, ISO C++ language for native code, C++/CLI
language for interaction with the .NET VM + .NET VM. The plus of this is
that all these can be combined, native code with VM code.

I am not sure how pretty C++/CLI is though (I learned .NET programming
with "C++ managed extensions", the "ancestor" of C++/CLI), however while
C++/CLI was under development it was breaking common C++ semantics (like
default inheritance for "managed classes" being public instead of
private), while "C++ managed extensions" that I learned didn't break these.

 

[Sam]

You don't change much.

My point exactly. You're arguing for the sake of arguing.

Certainly. The garbage collector never invokes object
destruction. The two things are separate concepts, and as such
should be disassociated.

Irrelevant. Whether or not they are separate concepts reflects nothing on
the fact that separating their respective occurences buys you nothing, or
makes any sense.

What do you mean, finally. This has always been a fundamental
concept for any competent programmer.

Not the ones that rely on garbage collection. After all, if they did
undertand the concept, they would understand when their objects' lifetime
has expired, and they can be destroyed and their memory gets reclaimed.

What you seem to be missing is the "if". In a lot of
applications, that if will usually be false, so the then part of
the sentence doesn't apply. Obviously, you need to do the
analysis to determine if it applies, but you need to do that
anyway, garbage collection or not---you need to know what to put
in the destructor before you write it. The difference when
using garbage collection is that if that analysis shows that
nothing really needs to be done (except memory management),
you're through. You've finished the job. Without garbage
collection, you've still got code to write.

You seem to be carrying a misunderstanding that just because an explicit
class destructor is not required, it must mean that the class destructor
does not exist.

That, of course, is wrong. The class may, for example, contain member
objects that themselves have an explicit destructor. Therefore, even if you
do not need to code an explicit destructor, it still, heavens-to-Betsy,
exists. For the obvious reasons.

So you really can't just wash your hands of the whole matter, by the virtue
of claiming that you do not need to write a destructor for your class.
That's because there's always a destructor, for every class. Just because
you do not have to explicitly define one, does not mean that the class
destructor does not exist. This does not excuse you from the resposibility
of properly implementing your object's lifetime, and instead foisting it off
on some sloppy garbage collector.

Generic garbage collection in the C++ context never takes form of "well, you
explicitly invoke the destructor when you should, and I'll take care of
releasing the memory at some point later down the line". It's always "well,
don't worry about the objects, when I figure out they're no longer needed,
I'll destroy them and reclaim their memory".

Maybe. You might want to keep it as long as there are pointers
to it, for error checking.

Brilliant. And when you figure out that no such pointers exists, you're
going to finally kiss it good-bye, right? It's amazing how better this
approach is, rather than just using shared_ptr (or a better implemented
alternative). Why have to use such a bland concept like shared_ptr, when you
can use this wonderfully-convoluted object model?

You gain robustness, when you need to explicitly dispose of the
object, and a lot less code to write, when you don't.

You certainly need a lot less code to write if you disclaim the
responsibility of properly tracking the objects' lifetime, and foisting it
off on some garbage collection algorithm.

I would not call that "robust", by any stretch of imagination.

Garbage collection isn't a model. It's a tool. Maybe that's
where you're having problems with it.

Here's another hair to split, for you: _____________________

Of course it's a tool. It's a tool for those who are too lazy, or
incompetent, to properly design their classes, and track their instances'
lifetime.

Which, of course, is false. No professional, today, would start
a new C++ application without considering garbage collection,
any more than he'd start it without considering templates, or
threads, or any other feature readily available.

Your definition of "professional" does not seem to be the same one as
mine's. If I see someone's spaghetti code missing the obvious deletes, in
the appropriate places, I ask them about it, and they say "oh, don't worry
about, the garbage collector will take care of it", I would not describe
such a person as a "professional".


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

iD8DBQBHys3Yx9p3GYHlUOIRAgnrAJ0evman3KgviTw8DhjNiHECMZd6DgCcDTqH
IXHWQO39MgcSASUDq/2+98M=
=GAp0
-----END PGP SIGNATURE-----

 

[Sam]

Unless you've modified the JVM in some way, that simply cannot
happen. When Java runs out of memory, it automatically triggers
garbage collection. It sounds more like your application had a
memory leak. (Note that memory leaks are also possible without
garbage collection. In fact, garbage collection reduces the
risk of memory leaks. Without bringing it down to zero, of
course.)

Don't take my word for it.

http://java.sun.com/docs/white/langenv/Simple.doc1.html

# The Java run-time system takes advantage of these idle periods and runs
# the garbage collector in a low priority thread when no other threads are
# competing for CPU cycles.



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

iD8DBQBHys3kx9p3GYHlUOIRAqqhAJ9Mjwj4/jRtZoxKNDJ3UdfptBRWGQCfRT0Z
DTzRauZZL933CKgmSh3CJ/4=
=TkaR
-----END PGP SIGNATURE-----

 

[Sam]

It's becoming more and more apparent that you don't really know
either C++ or Java. In both languages, a file descripter is
freed when you close the file. Nothing to do with garbage
collection.

It's already apparent that you don't really understand the problems with
garbage collection, as it gets clearly demonstrated the Java model, and why
it forces you to explicitly code exception handling, when dealing with
external resources, thus defeating the very thing that's touted as Java's
advantage of not forcing the programmer to manage the object's lifetimes,
and letting the VM take care of it.

I'll spell it out, but just once. You're constructing a java object that
contains a java.io.File, as one of its members (or any other object that
refers to some external resource). Right after you acquire the external
resource (by opening the file, or an equivalent operation on another type of
a resource), you must immediately have a try/catch block that will release
the external resource if an exception occurs before the object gets
completely constructed. Because if one occurs and you don't catch it, then,
due to the wonders of the Java VM, that java.io.File object will still exist
and claim the external resource, until the VM decides to GC it. So, lather,
rinse, repeat, and you're out of file descriptors, since the VM thinks it
still has plenty of memory, and it doesn't bother to finalize and collect
all the java.io.File objects that are littering the heap.

And you now have to percolate and code the same clumsy exception handling
all the way up your class hierarchy, and with anything else that touches any
part of this class hierarchy. Your homework assignment is to figure out why.

There you go, the wonderful advantages of garbage collection, for you.

Or destructors, really---you need to check the
return code of the close(), and do something if the close fails,
so you really can't defer it to the constructor anyway.

WHOOOOOOOOOOOOSH!!! Right over your head, again.



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

iD8DBQBHys4jx9p3GYHlUOIRAtGIAJ9NMO+FNeLVWs2+UcgF/KirDULYhgCfWOpe
vOVi7dj6hN9F/xY+to4egmA=
=3F1v
-----END PGP SIGNATURE-----