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 (remove nospam from address) wrote:
> I'm assuming the the following happen behind the scenes.
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.
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]
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.
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.
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.
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
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!

Signature
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.
Ioannis Vranos - 17 Jul 2004 02:06 GMT
> 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.
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
Tomas Restrepo \(MVP\) - 17 Jul 2004 04:19 GMT
Ioannis,
> Please explain me the following about C++/CLI draft as it is currently:
>
[quoted text clipped - 9 lines]
> When this is destroyed at the end of the scope, the memory allocated is
> freed or only the destructor is called?
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?
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?
>
[quoted text clipped - 7 lines]
>
> delete p;
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?
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...

Signature
Tomas Restrepo
tomasr@mvps.org
Ioannis Vranos - 17 Jul 2004 09:55 GMT
Tomas Restrepo (MVP) wrote:
>>4) What is the exact reason that templates cannot work with CLI types
>>and we need special versions of STL facilities?
[quoted text clipped - 6 lines]
> that's a different story altogether. I think Ronald Laeremans provided a
> much better answer that I could about that a few days ago...
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
Brandon Bray [MSFT] - 17 Jul 2004 22:50 GMT
> What is the exact reason that templates cannot work with ref types and
> we need special versions of STL facilities?
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.

Signature
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.
Ioannis Vranos - 17 Jul 2004 23:37 GMT
>>What is the exact reason that templates cannot work with ref types and
>>we need special versions of STL facilities?
[quoted text clipped - 9 lines]
>
> Regarding the structure of STL for .NET or for Standard C++, it is the same.
That's great news!
Regards,
Ioannis Vranos
Hasani \(remove nospam from address\) - 23 Jul 2004 15:03 GMT
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.
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.
> Hasani (remove nospam from address) wrote:
> > I'm assuming the the following happen behind the scenes.
[quoted text clipped - 69 lines]
>
> Hope that helps!