Question about garbage collection in in vc++ 2005

  • Thread starter Thread starter Guest
  • Start date Start date
Hasani said:
I was reading a ppt ( http://www.gotdotnet.com/team/pdc/4064/tls310.ppt )
and came aross this statement.

"Users can leverage a destructor. The C++ compiler generates all the
Dispose code automatically, including chaining calls to Dispose. (There
is no Dispose pattern)"

but Dispose can thrown an exception. Is the exception supressed?
Click to expand...

Destructors can throw exceptions too. They are not suppressed. Since
destruction is deterministic, most of the time you can handle the exception
yourself. When an exception is thrown from a destructor while another
exception is unwinding the stack, the exceptions are linked together.

Of course, it is recommended that you not throw exceptions from destructors.
(The same is true if you are writing Dispose in other languages.)
 
I just want to make sure I'm getting this right.
In the next release of c++.net, lets assume the following code

===============================

#using <mscorlib.dll>

using namespace System;
using namespace System::Net::Sockets;

public __gc class Foo : public IDisposable
{
public:
Foo()
{
_socket = new
System::Net::Sockets::Socket(AddressFamily::InterNetwork,
SocketType::Stream, ProtocolType::Tcp);
_isocket = dynamic_cast<IDisposable*>(socket);
}

void IDisposable::Dispose()
{
_isocket->Dispose();
}

~Foo()
{
try
{
Dispose();
}
catch(...)
{
}
}

__property Socket* get_Socket()
{
//TODO: do check to make sure object is not disposed.
return _socket;
}

private:
System::Net::Socket __gc* _socket;
IDisposable __gc* _isocket;
};

int main(int argc, char* argcv[])
{
{
Foo f;
Object __gc* socket = f.Socket;
}
//the desctructor should have been called by now.
return 0;
}

==========================

I'm assuming the the following happen behind the scenes.

1) f.Dispose() will be called automatically in the same thread context in
which f was initialized and no exception handling being performed
if f.dtor() throws an exception.
2) f.dtor() [same text as 1]
3) there is no excpetion handling performed when f.Dispose() and the
f.dtor() is automatically called.
4) the private variable f._socket will not be finalized instantly when
variable, f, goes out of scope. It will be finalized the next time garbage
collection is performed by either the system, or a call to GC::Collect.
5) When I say automatically, this is done at compile time and not runtime.
the compiler adds code to do 1, 2 and 3. 4 would be at runtime.

Thx in advance, I'm just trying to get a solid understanding of this new
feature of c++.net.

Also, if an object contains a finalizer, such as the Regex class. In the
next version of c++, will finalizers be treated as destructors so I can do

Regex __gc* regex = new Regex();
delete regex;
 
Hasani said:
I'm assuming the the following happen behind the scenes.
Click to expand...

First note that in the old syntax, deterministic cleanup is not available.
That is a feature of the new syntax. I'll answer your questions in terms of
the old syntax, and separately call out anything interesting about the new
syntax.

Also, note that in the old syntax ~Class maps to the finalizer of the class
(even though it generates a __dtor method). In the new syntax, ~Class maps
to Dispose (which is the destructor), and !Class maps to the finalizer.
1) f.Dispose() will be called automatically in the same thread context in
which f was initialized and no exception handling being performed if
f.dtor() throws an exception.
Click to expand...

Note that F (being a reference class) cannot be instantiated on the stack in
the old syntax. So, if it were created with a __gc pointer, the old syntax
would still allow F::Dispose to be called from the finalizer thread (which
is different than the thread f was created on).

The new syntax does allow F to be created on the stack, in which case its
destructor (i.e. Dispose) will be called at the end of the scope even if an
exception takes place. Thus, the finalizer should never run.
2) f.dtor() [same text as 1]
Click to expand...

In the old syntax, if Dispose is not run, the finalizer will. If Dispose is
run, it is very likely that the finalizer will not.

In the new syntax, the C++ generated destructor suppresses finalization.
3) there is no excpetion handling performed when f.Dispose() and the
f.dtor() is automatically called.
Click to expand...

The question doesn't make sense. Perhaps you are asking, in the presence of
an exception, does Dispose and dtor get called?

If that is the question, the answer is no (both of the them cannot be
called). Depending on what try/__finally blocks you have in the old syntax,
the Dispose may run. If it does, the finalizer probably will not. If Dispose
doesn't run, the finalizer will run.

In the new syntax, if the type is allocated on the stack, then it will have
its destructor (i.e. Dispose) called if an exception occurs.
4) the private variable f._socket will not be finalized instantly when
variable, f, goes out of scope. It will be finalized the next time garbage
collection is performed by either the system, or a call to GC::Collect.
Click to expand...

That is correct. If the destructor does not clean up the Socket (i.e. call
the Socket's destructor), the Socket will be finalized.
5) When I say automatically, this is done at compile time and not runtime.
the compiler adds code to do 1, 2 and 3. 4 would be at runtime.
Click to expand...

Yes, the compiler does all of the above in new syntax. If you are using the
old syntax, it does not do this.
Also, if an object contains a finalizer, such as the Regex class. In the
next version of c++, will finalizers be treated as destructors so I can do
Click to expand...

No. Finalizers and destructors are two different things. A finalizer gets
called when a destructor was not called. We map destructors to the Dispose
method from IDisposable. So, if you define a destructor in any ref class,
C++ will generate the Dispose pattern for you. It will also chain
destructors as usual. So, using the delete keyword on an object will
ultimately cause the Dispose method to be called.

Because the C++ compiler generates Dispose for you, you cannot write Dispose
yourself. Instead, you need to use destructor syntax.

Hope that helps!
 
Brandon said:
First note that in the old syntax, deterministic cleanup is not available.
That is a feature of the new syntax. I'll answer your questions in terms of
the old syntax, and separately call out anything interesting about the new
syntax.
Click to expand...


Please explain me the following about C++/CLI draft as it is currently:


1) Can we create an object of a ref class in the stack?

ref class test
{
// ...
};

test a;

When this is destroyed at the end of the scope, the memory allocated is
freed or only the destructor is called?


2) When we call delete on a handle pointing to an object in the free
store of a ref type, the destructor is called but is the memory freed?



3) Can we do this?


ref class test
{
// ...
};


// A test in the unmanaged heap
test *p=new test;

delete p;



4) What is the exact reason that templates cannot work with CLI types
and we need special versions of STL facilities?






Regards,

Ioannis Vranos
 
Ioannis,
Please explain me the following about C++/CLI draft as it is currently:


1) Can we create an object of a ref class in the stack?

ref class test
{
// ...
};

test a;

When this is destroyed at the end of the scope, the memory allocated is
freed or only the destructor is called?
Click to expand...

Neither. At least not exactly. If the type implements IDisposable (which in
C++/CLI is created through the destructor syntax ~test), then the object
will be disposed at the end of the scope. If it doesn't, then nothing
happens. In neither case is the memory of the object actually deallocated;
that's left to the GC, as usual.
2) When we call delete on a handle pointing to an object in the free
store of a ref type, the destructor is called but is the memory freed?
Click to expand...

IDisposable::Dispose is called, if the object implements that (again,
destructor syntax is now Disposable, while finalizers have a different one).
Again, memory is freed by the GC.
3) Can we do this?


ref class test
{
// ...
};


// A test in the unmanaged heap
test *p=new test;

delete p;
Click to expand...

Nope. reference type objects need to be allocated inside the GC heap.
4) What is the exact reason that templates cannot work with CLI types
and we need special versions of STL facilities?
Click to expand...

I think you're asking two different questions here. Templates *do* work with
CLI types in C++/CLI. Actually, it is the only language supporting both
generics *and* templates; which is quite powerful.

The second questions is the need for a STL-like facility for GC types, and
that's a different story altogether. I think Ronald Laeremans provided a
much better answer that I could about that a few days ago...
 
Tomas said:
I think you're asking two different questions here. Templates *do* work with
CLI types in C++/CLI. Actually, it is the only language supporting both
generics *and* templates; which is quite powerful.

The second questions is the need for a STL-like facility for GC types, and
that's a different story altogether. I think Ronald Laeremans provided a
much better answer that I could about that a few days ago...
Click to expand...


OK yes, I rephrase the question.

What is the exact reason that templates cannot work with ref types and
we need special versions of STL facilities?






Regards,

Ioannis Vranos
 
Ioannis said:
What is the exact reason that templates cannot work with ref types and
we need special versions of STL facilities?
Click to expand...

Templates can work with ref classes, interfaces, and value classes. That is
a feature we added in Whidbey (it wasn't a limitation of the language, but
rather a limitation of the metadata merge step when linking the program).

We are creating a new STL library specifically for .NET so that it (1) can
be verifiable, (2) interoperate with the Framework libraries, such as
passing a vector to an IList interface, and (3) can pass collections between
assemblies through generics.

Regarding the structure of STL for .NET or for Standard C++, it is the same.
 
Brandon said:
Templates can work with ref classes, interfaces, and value classes. That is
a feature we added in Whidbey (it wasn't a limitation of the language, but
rather a limitation of the metadata merge step when linking the program).

We are creating a new STL library specifically for .NET so that it (1) can
be verifiable, (2) interoperate with the Framework libraries, such as
passing a vector to an IList interface, and (3) can pass collections between
assemblies through generics.

Regarding the structure of STL for .NET or for Standard C++, it is the same.
Click to expand...



That's great news!






Regards,

Ioannis Vranos
 
Thx for the answers. I have another question though. Since in the new
version of c++, the Dispose now links to the destructor, how will this
affect code written in vc7/7.1
Because the C++ compiler generates Dispose for you, you cannot write Dispose
yourself. Instead, you need to use destructor syntax.
Click to expand...

I am curious as to would would happen if I had a class written in an older
verion of c++ that implements IDisposable, and also has a desctructor? Will
calling delete Class invoke the destructor or the dispose method? I'm
assuming it will invoke the dispose method.

Brandon Bray said:
Hasani said:
I'm assuming the the following happen behind the scenes.
Click to expand...

First note that in the old syntax, deterministic cleanup is not available.
That is a feature of the new syntax. I'll answer your questions in terms of
the old syntax, and separately call out anything interesting about the new
syntax.

Also, note that in the old syntax ~Class maps to the finalizer of the class
(even though it generates a __dtor method). In the new syntax, ~Class maps
to Dispose (which is the destructor), and !Class maps to the finalizer.
1) f.Dispose() will be called automatically in the same thread context in
which f was initialized and no exception handling being performed if
f.dtor() throws an exception.
Click to expand...

Note that F (being a reference class) cannot be instantiated on the stack in
the old syntax. So, if it were created with a __gc pointer, the old syntax
would still allow F::Dispose to be called from the finalizer thread (which
is different than the thread f was created on).

The new syntax does allow F to be created on the stack, in which case its
destructor (i.e. Dispose) will be called at the end of the scope even if an
exception takes place. Thus, the finalizer should never run.
2) f.dtor() [same text as 1]
Click to expand...

In the old syntax, if Dispose is not run, the finalizer will. If Dispose is
run, it is very likely that the finalizer will not.

In the new syntax, the C++ generated destructor suppresses finalization.
3) there is no excpetion handling performed when f.Dispose() and the
f.dtor() is automatically called.
Click to expand...

The question doesn't make sense. Perhaps you are asking, in the presence of
an exception, does Dispose and dtor get called?

If that is the question, the answer is no (both of the them cannot be
called). Depending on what try/__finally blocks you have in the old syntax,
the Dispose may run. If it does, the finalizer probably will not. If Dispose
doesn't run, the finalizer will run.

In the new syntax, if the type is allocated on the stack, then it will have
its destructor (i.e. Dispose) called if an exception occurs.
4) the private variable f._socket will not be finalized instantly when
variable, f, goes out of scope. It will be finalized the next time garbage
collection is performed by either the system, or a call to GC::Collect.
Click to expand...

That is correct. If the destructor does not clean up the Socket (i.e. call
the Socket's destructor), the Socket will be finalized.
5) When I say automatically, this is done at compile time and not runtime.
the compiler adds code to do 1, 2 and 3. 4 would be at runtime.
Click to expand...

Yes, the compiler does all of the above in new syntax. If you are using the
old syntax, it does not do this.
Also, if an object contains a finalizer, such as the Regex class. In the
next version of c++, will finalizers be treated as destructors so I can
Click to expand...
do

No. Finalizers and destructors are two different things. A finalizer gets
called when a destructor was not called. We map destructors to the Dispose
method from IDisposable. So, if you define a destructor in any ref class,
C++ will generate the Dispose pattern for you. It will also chain
destructors as usual. So, using the delete keyword on an object will
ultimately cause the Dispose method to be called.

Because the C++ compiler generates Dispose for you, you cannot write Dispose
yourself. Instead, you need to use destructor syntax.

Hope that helps!
Click to expand...
 
Back
Top