Tale of the __dtor method and the delete operator

Last week, I was reviewing the Managed C++ MOC course as I was scheduled to give it to an ISV. Something I read triggered my curiosity.


I was wondering what

delete p ; delete p ;

would mean in Managed C++ as I know the second call is undefined behaviour in Standard C++. The memory block is gone after all.


So I followed what was going on under the VS.NET debugger and I realized that all it does is calling the __dtor member that in turn calls System::GC::SuppressFinalize and then the Finalize method (the actual code specified in your Managed C++ destructor).

As p still refers to a block of memory in the Managed Heap, you could potentially call delete multiple times without having bad side effects. (depends on how robust/paranoiac the destructor/Finalize method code is I guess)


I can even define that method in a C# class and now, I can delete it from Managed C++.

// C#
class Class1


public Class1()



      public void __dtor()


         Console.WriteLine( "\"C++ Destructor\"" ) ;




// MC++
ToDelete::Class1 * pClass1 = new ToDelete::Class1() ;
delete pClass1 ;

Not that I would advise people to do this: let's stick to the IDisposable pattern. Have you heard about the deterministic cleanup feature in Whidbey MC++? 


Then, out of curiosity, I tried a query on Google __dtor +site:microsoft.com and well, all I deduce is that a lot of things in Longhorn are written in MC++!


But I did not find any good article/doc about that __dtor thing.


Later, I went where I should have started: ILDasm.

.method public instance void  __dtor() cil managed


  // Code size       13 (0xd)

  .maxstack  1

  IL_0000:  ldarg.0

  IL_0001:  call       void [mscorlib]System.GC::SuppressFinalize(object)

  IL_0006:  ldarg.0

  IL_0007:  callvirt   instance void TestClass::Finalize()

  IL_000c:  ret

} // end of method TestClass::__dtor



I wonder if all I found and just wrote is correct. I'll check with the C++ team.


What is the value of all this? Well, as C++ developers, we like to understand all the details about what's going on behind the fence, don't we?


Which remind me of another topic for an entry: the need to look at details (IL) from time to time if you want performance from you MC++/C#/VB.NET software.


Arrivederci et à demain, si on le veut bien.

Comments (0)

Skip to main content