What makes a class IDisposable?
-
In C++/CLI, both
classandstructare reference types. They need to be explicitly modified using thevaluekeyword to get a value type. My original problem is a design flaw. If I use a smart pointer, I don't need a destructor anymore and the problem goes away. -- modified at 11:11 Monday 13th August, 2007Luc Pattyn wrote:
there is no such thing as a destructor
Are you sure about that? I made this class:
class Class1
{
public Class1()
{
Console.WriteLine( "Class1 constructed." );
}~Class1() { Console.WriteLine( "Class1 destructed." ); }}
and I got "Class1 destructed." in my Output window. It was not deterministic, but it was called.
His post was C# specific, which is quite different from C++/CLI in some ways. In C# there is no destructor. The destructor syntax in C# ( ~Class1() ) is actually a finalizer. In C++/CLI ~Class1() maps to the Dispose() function from IDisposable giving you a form of deterministic destruction (though memory won't be reclaimed immediately you can count on resources being closed). The !Class() syntax maps to the finalizer in C++/CLI.
-
His post was C# specific, which is quite different from C++/CLI in some ways. In C# there is no destructor. The destructor syntax in C# ( ~Class1() ) is actually a finalizer. In C++/CLI ~Class1() maps to the Dispose() function from IDisposable giving you a form of deterministic destruction (though memory won't be reclaimed immediately you can count on resources being closed). The !Class() syntax maps to the finalizer in C++/CLI.
-
Class1is a C# class. Take up the semantic argument with Microsoft for putting a "Destructors (C# Programming Guide)" page in the MSDN library. -
Class1is a C# class. Take up the semantic argument with Microsoft for putting a "Destructors (C# Programming Guide)" page in the MSDN library.oh right, wasn't paying close enough attention. And yes MS semantics are horribly confusing. In that case, the C# ~Class1() is the finalizer. And by explicitly defining one you ensure that it is called by the garbage collector before the memory for an instance of the class is reclaimed. So although you're printing 'destructed' its actually the garbage collector calling the finalizer before memory is reclaimed. Its not a destructor that runs when the variable goes out of scope as you would get if it was a C++/CLI
ref classwith ~Class1() defined. And unlike destruction, finalization is nondeterministic and incurs a high performance cost for both allocation and deallocation. So you never want to write one unless your class contains unmanaged resources that won't be cleaned up by the garbage collector. In that case the finalizer will ensure the unmanaged stuff is cleaned up even if someone forgets to calldeleteorDispose. -
oh right, wasn't paying close enough attention. And yes MS semantics are horribly confusing. In that case, the C# ~Class1() is the finalizer. And by explicitly defining one you ensure that it is called by the garbage collector before the memory for an instance of the class is reclaimed. So although you're printing 'destructed' its actually the garbage collector calling the finalizer before memory is reclaimed. Its not a destructor that runs when the variable goes out of scope as you would get if it was a C++/CLI
ref classwith ~Class1() defined. And unlike destruction, finalization is nondeterministic and incurs a high performance cost for both allocation and deallocation. So you never want to write one unless your class contains unmanaged resources that won't be cleaned up by the garbage collector. In that case the finalizer will ensure the unmanaged stuff is cleaned up even if someone forgets to calldeleteorDispose.I don't want to argue, but you're not being specific enough. A C# destructor is more than syntactic sugar. The code within it will be called and then an implicit call is made to Finalize(). I'm not disputing or judging what actually occurs, I'm just pointing out that "C# destructors do not exist" is not a true statement. And I'm certainly not advocating that every C# class define a destructor. I'm glad I made my original mistake in assuming that C++/CLI ctor/dtor behavior is the same as C++ ctor/dtor behavior because it cleared things up after clouding them for awhile.
-
In C++/CLI, both
classandstructare reference types. They need to be explicitly modified using thevaluekeyword to get a value type. My original problem is a design flaw. If I use a smart pointer, I don't need a destructor anymore and the problem goes away. -- modified at 11:11 Monday 13th August, 2007Luc Pattyn wrote:
there is no such thing as a destructor
Are you sure about that? I made this class:
class Class1
{
public Class1()
{
Console.WriteLine( "Class1 constructed." );
}~Class1() { Console.WriteLine( "Class1 destructed." ); }}
and I got "Class1 destructed." in my Output window. It was not deterministic, but it was called.
Yes indeed, there is a destructor-like syntax, but it is actually called a finalizer; it is a bit confusing if you ask me. And as you said it has undeterministic behavior: It gets executed by the gc when it decides to collect the object. :)
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/... - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google
-
I don't want to argue, but you're not being specific enough. A C# destructor is more than syntactic sugar. The code within it will be called and then an implicit call is made to Finalize(). I'm not disputing or judging what actually occurs, I'm just pointing out that "C# destructors do not exist" is not a true statement. And I'm certainly not advocating that every C# class define a destructor. I'm glad I made my original mistake in assuming that C++/CLI ctor/dtor behavior is the same as C++ ctor/dtor behavior because it cleared things up after clouding them for awhile.
That's just it though, it is syntactic sugar. When you write ~Class1() in C# you've got a finalizer. It's not doing something then calling
Finalize()I don't believe. Internally the compiler synthesizes that to a call toDispose(false)which is invoked by the garbage collector right before the memory is reclaimed nondeterministically. By contrast, a destructor in C++/CLI is synthesized toDispose() { Dispose(true); GC::SuppressFinalize(); }While a call to !Class1() in C++/CLI (the finalizer) results in a call toDispose(false). The ~Class1() is a finalizer, not a destructor. To call it a destructor is a complete misnomer and doesn't convey when or how its called. A destructor would be called automatically when the object goes out of scope (via ausingblock in C# or via stack semantics in C++/CLI) or when invoked specifically byDispose(). You must not reference other finalizable objects in that finalizer and other similar rules for finalizers that aren't present in a destructor. In C++/CLI a class destructor is created by the compiler automatically and will clean up managed resources for you. A finalizer (~Class1() in C#) is not generated by the compiler. It only exists if you explicitly write one. Most important is the fact that the ~Class1() in C# is nondeterminitic which by its nature makes it not a destructor (since they're deterministic) and the performance penalty for creating a finalizer for a class (In C++/CLI you would incur this cost with !Class1() but ~Class1() would enable actual RAII destructor semantics like native C++). In C++/CLI you would write ~Class1() to properly handle the closing of resources in a way that can be done deterministically (when the object goes out of scope or a call todeleteis made). This is a destructor. In C# when you write ~Class1() you're providing a way for the garbage collector to handle resource cleanup or unmanaged cleanup at the last second before memory reclamation in the case that the user failed to manually release it withDisposeor ausingblock. This is a finalizer. There is no destructor. You can't call delete. You have to write aDisposemethod and/or useusingblocks. The C++/CLI dtor/ctor behavior is semantically the same as native C++. Although the destructor in C++/CLI doesn't cause the memory to actually be reclaimed (as that's always the garbage collectors job for managed objects) it is invo -
That's just it though, it is syntactic sugar. When you write ~Class1() in C# you've got a finalizer. It's not doing something then calling
Finalize()I don't believe. Internally the compiler synthesizes that to a call toDispose(false)which is invoked by the garbage collector right before the memory is reclaimed nondeterministically. By contrast, a destructor in C++/CLI is synthesized toDispose() { Dispose(true); GC::SuppressFinalize(); }While a call to !Class1() in C++/CLI (the finalizer) results in a call toDispose(false). The ~Class1() is a finalizer, not a destructor. To call it a destructor is a complete misnomer and doesn't convey when or how its called. A destructor would be called automatically when the object goes out of scope (via ausingblock in C# or via stack semantics in C++/CLI) or when invoked specifically byDispose(). You must not reference other finalizable objects in that finalizer and other similar rules for finalizers that aren't present in a destructor. In C++/CLI a class destructor is created by the compiler automatically and will clean up managed resources for you. A finalizer (~Class1() in C#) is not generated by the compiler. It only exists if you explicitly write one. Most important is the fact that the ~Class1() in C# is nondeterminitic which by its nature makes it not a destructor (since they're deterministic) and the performance penalty for creating a finalizer for a class (In C++/CLI you would incur this cost with !Class1() but ~Class1() would enable actual RAII destructor semantics like native C++). In C++/CLI you would write ~Class1() to properly handle the closing of resources in a way that can be done deterministically (when the object goes out of scope or a call todeleteis made). This is a destructor. In C# when you write ~Class1() you're providing a way for the garbage collector to handle resource cleanup or unmanaged cleanup at the last second before memory reclamation in the case that the user failed to manually release it withDisposeor ausingblock. This is a finalizer. There is no destructor. You can't call delete. You have to write aDisposemethod and/or useusingblocks. The C++/CLI dtor/ctor behavior is semantically the same as native C++. Although the destructor in C++/CLI doesn't cause the memory to actually be reclaimed (as that's always the garbage collectors job for managed objects) it is invoFrom the source code perspective, I have code in a destructor that gets called. That's it. I'm not concerned with what goes on underneath. We're debating semantics. When you write
~Class1()in C#, you've got a destructor, both in name and behavior. In native C++, one would expect a destructor to be called implicitly when an automatic variable goes out of scope. Such is not the case in C++/CLI. What's defined as a destructor in C++/CLI does not get called when an automatic variable goes out of scope. What's defined as a finalizer in C++/CLI gets called when an automatic variable goes out of scope. That, to me, is a big difference. -
From the source code perspective, I have code in a destructor that gets called. That's it. I'm not concerned with what goes on underneath. We're debating semantics. When you write
~Class1()in C#, you've got a destructor, both in name and behavior. In native C++, one would expect a destructor to be called implicitly when an automatic variable goes out of scope. Such is not the case in C++/CLI. What's defined as a destructor in C++/CLI does not get called when an automatic variable goes out of scope. What's defined as a finalizer in C++/CLI gets called when an automatic variable goes out of scope. That, to me, is a big difference.You seem to be confused. You have to be concerned with what goes on underneath or you won't understand how this works. When you write
~Class1()in C# you have a finalizer in behavior. The syntax is like a C++ destructor and this is confusing on Microsoft's part. Assume you have a C# class with~Class1()defined. Now, whenever you instantiate an object of Class1 you incur a performance penalty simply because the finalizer exists. The Class1 instance must register in a Finalizable queue and an freachable queue when the GC does its business. ~Class1() (really a call toDispose(false)) will be invoked by the garbage collector every time an object of Class1 is about to be reclaimed. The simple existence of~Class1()and the subsequent placement in the freachable queue can cause objects of Class1 to be promoted to another generation and not be collected by the GC when it really could be. Most importantly, you have no idea when~Class1()will be called by the garbage collector. Its completely nondeterministic. This by its very nature means its not a destructor. The finalizer is there to let you code last minute cleanup of unmanaged resources (which the GC cannot work with) in case the user of your class did not properly callDispose()on an instance of Class1 or use ausingblock. And like I said before, there's a huge number of restrictions for what you can do in a finalizer vs a destructor. Now assume we have Class1 in C++/CLI with~Class1()defined. This will be called when an object of Class1 goes out of scope IF you declared that object with stack semantics (i.e.,Class1 myClass1Object). If you dynamically allocate memory withgcnewthen you must usedeleteto invoke the destructor deterministically. This is the same as what happens in native C++. The difference in C++/CLI is that the memory itself won't be immediately reclaimed immediately (as that's the GC's job and it works nondeterministically) but that's not an issue. It will be reclaimed when more memory is required. The important part is that the destructor (~Class1()) will always be invoked implicitly when the automatic variable goes out of scope. A C# class with~Class1()defined does not function this way because in C#~Class1()is a finalizer not a destructor. So in C++/CLI you put resource-release code in your destructor~Class1()and then an automatic vari -
You seem to be confused. You have to be concerned with what goes on underneath or you won't understand how this works. When you write
~Class1()in C# you have a finalizer in behavior. The syntax is like a C++ destructor and this is confusing on Microsoft's part. Assume you have a C# class with~Class1()defined. Now, whenever you instantiate an object of Class1 you incur a performance penalty simply because the finalizer exists. The Class1 instance must register in a Finalizable queue and an freachable queue when the GC does its business. ~Class1() (really a call toDispose(false)) will be invoked by the garbage collector every time an object of Class1 is about to be reclaimed. The simple existence of~Class1()and the subsequent placement in the freachable queue can cause objects of Class1 to be promoted to another generation and not be collected by the GC when it really could be. Most importantly, you have no idea when~Class1()will be called by the garbage collector. Its completely nondeterministic. This by its very nature means its not a destructor. The finalizer is there to let you code last minute cleanup of unmanaged resources (which the GC cannot work with) in case the user of your class did not properly callDispose()on an instance of Class1 or use ausingblock. And like I said before, there's a huge number of restrictions for what you can do in a finalizer vs a destructor. Now assume we have Class1 in C++/CLI with~Class1()defined. This will be called when an object of Class1 goes out of scope IF you declared that object with stack semantics (i.e.,Class1 myClass1Object). If you dynamically allocate memory withgcnewthen you must usedeleteto invoke the destructor deterministically. This is the same as what happens in native C++. The difference in C++/CLI is that the memory itself won't be immediately reclaimed immediately (as that's the GC's job and it works nondeterministically) but that's not an issue. It will be reclaimed when more memory is required. The important part is that the destructor (~Class1()) will always be invoked implicitly when the automatic variable goes out of scope. A C# class with~Class1()defined does not function this way because in C#~Class1()is a finalizer not a destructor. So in C++/CLI you put resource-release code in your destructor~Class1()and then an automatic variI may be reading your comments wrong, but did you state a C++ ref class destructor is a finalizer? That's not the case. The destructor maps to Dispose() and a finalizer must be explicitly added. Destructors do not get called if you allocate an object on the managed heap and never explicitly delete it. The finalizer, however will be called when the handle no longer has any references to it and the GC gets around to cleaning it up. That's why native objects should be freed in a finalizer, not a destructor (although the destructor should call the finalizer - the compiler takes care of SuppressFinalize). Having to explicitly delete objects would be counterintuitive, as Michael originally stated. Being able to (deterministically) using the familiar C++ syntax, however, is a nice, powerful feature. Note I'm only referring to C++ - I'll make no comments about C# except for the related Dispose/Finalize pattern of CLR. :) Cheers, Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
You seem to be confused. You have to be concerned with what goes on underneath or you won't understand how this works. When you write
~Class1()in C# you have a finalizer in behavior. The syntax is like a C++ destructor and this is confusing on Microsoft's part. Assume you have a C# class with~Class1()defined. Now, whenever you instantiate an object of Class1 you incur a performance penalty simply because the finalizer exists. The Class1 instance must register in a Finalizable queue and an freachable queue when the GC does its business. ~Class1() (really a call toDispose(false)) will be invoked by the garbage collector every time an object of Class1 is about to be reclaimed. The simple existence of~Class1()and the subsequent placement in the freachable queue can cause objects of Class1 to be promoted to another generation and not be collected by the GC when it really could be. Most importantly, you have no idea when~Class1()will be called by the garbage collector. Its completely nondeterministic. This by its very nature means its not a destructor. The finalizer is there to let you code last minute cleanup of unmanaged resources (which the GC cannot work with) in case the user of your class did not properly callDispose()on an instance of Class1 or use ausingblock. And like I said before, there's a huge number of restrictions for what you can do in a finalizer vs a destructor. Now assume we have Class1 in C++/CLI with~Class1()defined. This will be called when an object of Class1 goes out of scope IF you declared that object with stack semantics (i.e.,Class1 myClass1Object). If you dynamically allocate memory withgcnewthen you must usedeleteto invoke the destructor deterministically. This is the same as what happens in native C++. The difference in C++/CLI is that the memory itself won't be immediately reclaimed immediately (as that's the GC's job and it works nondeterministically) but that's not an issue. It will be reclaimed when more memory is required. The important part is that the destructor (~Class1()) will always be invoked implicitly when the automatic variable goes out of scope. A C# class with~Class1()defined does not function this way because in C#~Class1()is a finalizer not a destructor. So in C++/CLI you put resource-release code in your destructor~Class1()and then an automatic variAre you being purposefully daft? I understand what's going on; I'm arguing that "C# does not have destructors" is an untrue statement. I'm not repudiating the mechanics. Dispute this: The C# language specification allows for the definition of destructors for class types.
-
I may be reading your comments wrong, but did you state a C++ ref class destructor is a finalizer? That's not the case. The destructor maps to Dispose() and a finalizer must be explicitly added. Destructors do not get called if you allocate an object on the managed heap and never explicitly delete it. The finalizer, however will be called when the handle no longer has any references to it and the GC gets around to cleaning it up. That's why native objects should be freed in a finalizer, not a destructor (although the destructor should call the finalizer - the compiler takes care of SuppressFinalize). Having to explicitly delete objects would be counterintuitive, as Michael originally stated. Being able to (deterministically) using the familiar C++ syntax, however, is a nice, powerful feature. Note I'm only referring to C++ - I'll make no comments about C# except for the related Dispose/Finalize pattern of CLR. :) Cheers, Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
I'm pretty sure we've said the same thing. However... You say destructors are not called on an object allocated on the managed heap which isn't strictly true. If you allocate it on the managed heap with
gcnewthen yes the destructor is never called if you don't manually calldelete. However, if you instantiate theref classobject with stack semantics then the destructor is called implicitly when the object goes out of scope (even though underneath its still allocated on the managed heap like allref classobjects). This is the critical addition to C++/CLI (vs MC++) that allowed for RAII style coding like native C++. Michael was claiming this is not the case (as it is in native C++) and that the finalizer is what is called, which is not correct. The finalizer will be called eventually either way if you define one, but the way things work is obviously much different than what a destructor provides. The confusion is that in C# when you declare~Class1()this is actually mapped to the finalizer (Dispose(false)) in the dispose pattern. C# has no concept of destructors like C++ or C++/CLI even though the semantics there look like you're declaring a destructor. In C++/CLI you accomplish the same thing by declaring!Class1()which more properly distinguishes the finalizer from the destructor. Then declaring ~Class1() in C++/CLI does a very different thing than~Class1()in C#. That's why in C# you need to explicitly callDispose()in afinallyblock or use ausingblock with things likeFileWriterobjects to ensure there is no resource leak. C++/CLI's destructor semantics provide the handy native C++ style,FileWriter fw;which will automatically be disposed of properly when it goes out of scope (deterministically). -
Are you being purposefully daft? I understand what's going on; I'm arguing that "C# does not have destructors" is an untrue statement. I'm not repudiating the mechanics. Dispute this: The C# language specification allows for the definition of destructors for class types.
From: http://en.wikipedia.org/wiki/Destructor\_(computer\_science) In object-oriented programming, a destructor (sometimes shortened to dtor) is a method which is automatically invoked when the object is destroyed. Its main purpose is to clean up and to free the resources which were acquired by the object along its life cycle and unlink it from other objects or resources invalidating any references in the process. The use of destructors is key to the concept of RAII. How in C# do you declare such a thing? A finalizer is not automatically invoked when the object is destroyed deterministically. It is nondeterministically called by the GC at some point in the future. Most important, in no way does a finalizer enable the RAII pattern. Take a
FileStreamclass which encapsulates a resource in C#. Declare a finalizer for it. When an instance of a FileStream class goes out of the scope the finalizer is not called then. You do not know when it is called. Furthermore, even if the GC does a collect and there are no roots in the code to the object, the simple existence of the finalizer counts as a root and can cause theFileStreamobject to be promoted into the next generation and not collected by the GC until the next collect cycle (who knows when that will be). So while yourFileStreamobject may have gone out of scope ages ago, by not callingDisposeand assuming the finalizer will close theFileStream, you have potentially caused a resource leak. The next function call that assumes the file you previously had used with theFileStreamobject is closed may throw an exception because you were relying on the garbage collector to nondeterministically release a critical resource. On the other hand, a destructor in C++/CLI will be called the moment theFileStreamgoes out of scope (assuming you declared the object with stack semantics and notgcnew). Then in the destructor you make sure there is a call toDisposeand you ensure that the resource is released immediately. You don't need atry/finallyand you don't need to explicitly callDisposeand nor does anyone who uses your class in the future. The destructor incurs no performance penalty during allocation or deallocation like a finalizer does either. There's no way to declare such a function in C#. To say 'I'm not repudiating the mechanics' therefore C# has destructors is completely wrong. The mechanics are exa -
From: http://en.wikipedia.org/wiki/Destructor\_(computer\_science) In object-oriented programming, a destructor (sometimes shortened to dtor) is a method which is automatically invoked when the object is destroyed. Its main purpose is to clean up and to free the resources which were acquired by the object along its life cycle and unlink it from other objects or resources invalidating any references in the process. The use of destructors is key to the concept of RAII. How in C# do you declare such a thing? A finalizer is not automatically invoked when the object is destroyed deterministically. It is nondeterministically called by the GC at some point in the future. Most important, in no way does a finalizer enable the RAII pattern. Take a
FileStreamclass which encapsulates a resource in C#. Declare a finalizer for it. When an instance of a FileStream class goes out of the scope the finalizer is not called then. You do not know when it is called. Furthermore, even if the GC does a collect and there are no roots in the code to the object, the simple existence of the finalizer counts as a root and can cause theFileStreamobject to be promoted into the next generation and not collected by the GC until the next collect cycle (who knows when that will be). So while yourFileStreamobject may have gone out of scope ages ago, by not callingDisposeand assuming the finalizer will close theFileStream, you have potentially caused a resource leak. The next function call that assumes the file you previously had used with theFileStreamobject is closed may throw an exception because you were relying on the garbage collector to nondeterministically release a critical resource. On the other hand, a destructor in C++/CLI will be called the moment theFileStreamgoes out of scope (assuming you declared the object with stack semantics and notgcnew). Then in the destructor you make sure there is a call toDisposeand you ensure that the resource is released immediately. You don't need atry/finallyand you don't need to explicitly callDisposeand nor does anyone who uses your class in the future. The destructor incurs no performance penalty during allocation or deallocation like a finalizer does either. There's no way to declare such a function in C#. To say 'I'm not repudiating the mechanics' therefore C# has destructors is completely wrong. The mechanics are exa -
Well like I said then, make sure to declare
~Class()in all your C# classes and don't bother explicitly invokingDispose. I'm sure you'll find it works fantastically. Also make sure to take advantage of finalizers to declare reference classes in C# with stack semantics. -- modified at 15:30 Monday 13th August, 2007 -
Well like I said then, make sure to declare
~Class()in all your C# classes and don't bother explicitly invokingDispose. I'm sure you'll find it works fantastically. Also make sure to take advantage of finalizers to declare reference classes in C# with stack semantics. -- modified at 15:30 Monday 13th August, 2007No need to get pissy. As I said earlier, I'm not advocating the use of what the language itself calls (or, apparently, used to call) a destructor; I'm just claiming that such a beast exists. From the C# Language Specification: [Note: In the previous version of this standard, what is now referred to as a "finalizer" was called a "destructor". Experience has shown that the term "destructor" caused confusion and often resulted to incorrect expectations, especially to programmers knowing C++. In C++, a destructor is called in a determinate manner, whereas, in C#, a finalizer is not. To get determinate behavior from C#, one should use Dispose. end note]
-
I'm pretty sure we've said the same thing. However... You say destructors are not called on an object allocated on the managed heap which isn't strictly true. If you allocate it on the managed heap with
gcnewthen yes the destructor is never called if you don't manually calldelete. However, if you instantiate theref classobject with stack semantics then the destructor is called implicitly when the object goes out of scope (even though underneath its still allocated on the managed heap like allref classobjects). This is the critical addition to C++/CLI (vs MC++) that allowed for RAII style coding like native C++. Michael was claiming this is not the case (as it is in native C++) and that the finalizer is what is called, which is not correct. The finalizer will be called eventually either way if you define one, but the way things work is obviously much different than what a destructor provides. The confusion is that in C# when you declare~Class1()this is actually mapped to the finalizer (Dispose(false)) in the dispose pattern. C# has no concept of destructors like C++ or C++/CLI even though the semantics there look like you're declaring a destructor. In C++/CLI you accomplish the same thing by declaring!Class1()which more properly distinguishes the finalizer from the destructor. Then declaring ~Class1() in C++/CLI does a very different thing than~Class1()in C#. That's why in C# you need to explicitly callDispose()in afinallyblock or use ausingblock with things likeFileWriterobjects to ensure there is no resource leak. C++/CLI's destructor semantics provide the handy native C++ style,FileWriter fw;which will automatically be disposed of properly when it goes out of scope (deterministically).iddqd515 wrote:
in C# when you declare ~Class1() this is actually mapped to the finalizer (Dispose(false)) in the dispose pattern.
Dispose() isn't the finalizer...Finalize() is, right? Regardless, C++ does the same - the destructor becomes Dispose() (quite literally, as Michael's original warning message stated). In C++ the Destructor is explicitly called when a stack-based syntax managed object goes out of scope, the destructor is called directly, a managed heap object is explicitly deleted with delete, or another language calls Dispose() on an object. If the class implements a finalizer then that needs to be (at least SHOULD be) called from the destructor. The compiler takes care of calling SuppressFinalize so the finalizer will not be called again by the GC. Isn't that the same as the C# (and probably VB) Dispose/Finalize pattern? Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
No need to get pissy. As I said earlier, I'm not advocating the use of what the language itself calls (or, apparently, used to call) a destructor; I'm just claiming that such a beast exists. From the C# Language Specification: [Note: In the previous version of this standard, what is now referred to as a "finalizer" was called a "destructor". Experience has shown that the term "destructor" caused confusion and often resulted to incorrect expectations, especially to programmers knowing C++. In C++, a destructor is called in a determinate manner, whereas, in C#, a finalizer is not. To get determinate behavior from C#, one should use Dispose. end note]
So that right there says 'sorry we incorrectly used to refer to this as a destructor. We realized it was confusing because its really not a destructor at all. To get destructor like behavior in C# use the Dispose method.' Therefore, C# has no destructors. And even in the past, it only had them in name, not function. But its been awhile since anyone referred to them as destructors since its blatantly confusing, especially with the introduction of C++/CLI in '05.
-
From: http://en.wikipedia.org/wiki/Destructor\_(computer\_science) In object-oriented programming, a destructor (sometimes shortened to dtor) is a method which is automatically invoked when the object is destroyed. Its main purpose is to clean up and to free the resources which were acquired by the object along its life cycle and unlink it from other objects or resources invalidating any references in the process. The use of destructors is key to the concept of RAII. How in C# do you declare such a thing? A finalizer is not automatically invoked when the object is destroyed deterministically. It is nondeterministically called by the GC at some point in the future. Most important, in no way does a finalizer enable the RAII pattern. Take a
FileStreamclass which encapsulates a resource in C#. Declare a finalizer for it. When an instance of a FileStream class goes out of the scope the finalizer is not called then. You do not know when it is called. Furthermore, even if the GC does a collect and there are no roots in the code to the object, the simple existence of the finalizer counts as a root and can cause theFileStreamobject to be promoted into the next generation and not collected by the GC until the next collect cycle (who knows when that will be). So while yourFileStreamobject may have gone out of scope ages ago, by not callingDisposeand assuming the finalizer will close theFileStream, you have potentially caused a resource leak. The next function call that assumes the file you previously had used with theFileStreamobject is closed may throw an exception because you were relying on the garbage collector to nondeterministically release a critical resource. On the other hand, a destructor in C++/CLI will be called the moment theFileStreamgoes out of scope (assuming you declared the object with stack semantics and notgcnew). Then in the destructor you make sure there is a call toDisposeand you ensure that the resource is released immediately. You don't need atry/finallyand you don't need to explicitly callDisposeand nor does anyone who uses your class in the future. The destructor incurs no performance penalty during allocation or deallocation like a finalizer does either. There's no way to declare such a function in C#. To say 'I'm not repudiating the mechanics' therefore C# has destructors is completely wrong. The mechanics are exaiddqd515 wrote:
On the other hand, a destructor in C++/CLI will be called the moment the FileStream goes out of scope (assuming you declared the object with stack semantics and not gcnew). Then in the destructor you make sure there is a call to Dispose
That may be where my confusion with your statements is coming from. That sounds like managed extensions. In VS 2005, you can't call Dispose() - the compiler won't let you. This is now done implicitly with the destructos symantics. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java: