> That is exactly the case for C++. In your above code f1(), the C++
compiler
> already (behind the scene) inserts finally block for "o" destructor. That
> is why the destructor of stack allocated objects is called even when
> exception
> happens. The only difference is that the memory deallocation is
> dis-associated
> with object destruction.
>
> Summary: the object destruction with GC is as deterministic as C++ heap
> allocated object, i.e. you have to call "delete x" (in C++), x.close()
(in
> Java), x.dispose (in C#), otherwise is 0% deterministic, period.
No, there is a difference. The difference is you do not know when the Java
garbage collector will call an object's finalize() method, and in fact Java
does not even guarentee it will be called at all. C#'s garbage collector is
nondeterministic as well. The garbage collector in these languages are
usually implemented to run on a low priority thread. This thread gets
processor time based on system load, which means objects are collected and
finalized based on thread scheduling, the number of active threads, and
other factors that have nothing to do with a function going out of scope
and which cannot be predicted prior to run time.
In C++, when operator delete is called, the object's destructor is invoked
as part of the call right away, not "at some point in the future, by some
other thread, maybe" as with Java.
This changes the way a programmer writes code. A C++ class and function
that uses the class looks like this:
class A
{
public:
A(){...grab some resources...}
~A(){...release the resources...}
}
void f()
{
A a;
... use a's resources ...
}
....looks like this in Java...
class A
{
public:
A(){...grab some resources...}
}
void f()
{
try
{
A a;
... use a's resources ...
}
finally
{
...release the resources...
}
}
....because we do not know when or if Java will finalize the "a" object. And
everywhere the programmer uses the class A he must write the finally block
as well. Also note that both examples behave correctly in the face of
exceptions thrown during the execution of f().
Dave
Hong Zhang
<Hong.Zhang@corp To:
.palm.com> cc: [EMAIL PROTECTED]
Subject: RE: How Powerful Is Parrot? (A
Few More Questions)
01/25/02 03:05
PM
> I believe the main difficulty comes from heading into uncharted waters.
For
> example, once you've decided to make garbage collection optional, what
does
> the following line of code mean?
>
> delete x;
If the above code is compiled to Parrot, it probably equivalent to
x->~Destructor();
i.e., the destructor is called, but the memory is left to GC, which most
likely
handle free at a later time.
> Or, for example, are the side effects of the following two functions
> different?
>
> void f1()
> {
> // On the stack
> MyClass o;
> }
>
> void f2()
> {
> // On the heap
> MyClass o = new MyClass();
> }
>
> If garbage collection is not 100% deterministic, these two functions
could
> produce very different results because we do not know when or if the
> destructor for MyClass will execute in the case of f2().
This is exactly the same case for C++. When you compile f2 with gcc, how
can you tell when the destructor is called. Even the following code does
not work.
void f3()
{
MyClass o = new MyClass();
...
delete o;
}
If there is an exception happens within (...), the destructor will not be
called.
> If garbage collection is
> not 100% deterministic (and Mark and Sweep is not), we need extra
language
> features, such as Java's "finally" block, to ensure things can be cleaned
> up, and extra training to ensure programmers are smart enough to know how
> to use "finally" blocks correctly.
That is exactly the case for C++. In your above code f1(), the C++ compiler
already (behind the scene) inserts finally block for "o" destructor. That
is why the destructor of stack allocated objects is called even when
exception
happens. The only difference is that the memory deallocation is
dis-associated
with object destruction.
Summary: the object destruction with GC is as deterministic as C++ heap
allocated object, i.e. you have to call "delete x" (in C++), x.close() (in
Java), x.dispose (in C#), otherwise is 0% deterministic, period.
Hong
