A
Akhil
How much is Pointers different in C# compared to C++?
Do we have destructors in C#? if yes, for what do we use it?
Do we have destructors in C#? if yes, for what do we use it?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
M
Morten Wennevik
Hi Akhil,
Very different. Pointers do not exist in C#. Although you can still use pointers in "unsafe" code blocks.
Basically no. You make sure there are no more references to an object and the garbage collector will release the memory shortly thereafter. You can still write a kind of destructor that will be called when the garbage collector is about to eat an object.
How much is Pointers different in C# compared to C++?
Very different. Pointers do not exist in C#. Although you can still use pointers in "unsafe" code blocks.
Do we have destructors in C#? if yes, for what do we use it?
Basically no. You make sure there are no more references to an object and the garbage collector will release the memory shortly thereafter. You can still write a kind of destructor that will be called when the garbage collector is about to eat an object.
G
Guest
There are a few things to be considered about pointers in C#:
(1) Any code using pointers cannot be 'managed' by CLR. So you've to put it
in 'unsafe' block.
(2) Any object in a program's memory can be garbage collected or moved to a
different location in memory without any notice by the garbage collector of
..NET runtime. To fix a pointer and memory pointed to by the pointer in
memory, you've to use 'fixed' clause. Any pointer declared inside a 'fixed'
expression will be pinned in memory and will not be moved by the GC.
(3) Any value types declared within an 'unsafe' block are automatically
treated as 'fixed' by the runtime and so these cannot appear within a 'fixed'
clause.
(4) As a guideline for use of pointers, you'll have to use them only when
execution speed is utmost important, or you've to call some Windows API
function which requires a pointer as a parameter.
About Destructors in C#:
(1) In general you don't need to worry about freeing memory. However when
your application encapsulates unmanaged resources such as windows, files, and
network connections, you should use destructors to free those resources.
(2) Destructor is called by the GC AFTER an object is marked for
destruction, that is when it is no longer refernced or it is no longer in
scope.
(3) The destructor implicitly calls the Object.Finalize() method.
(4) Destructors cannot be invoked explicitly. They cannot be inherited and
overloaded.
(5) Structs do not have destructors
(6) In general it's better to implement Dispose() method of IDisposable
interface and put the clean up code there, and call it whenever the object is
to be destroyed, because there is no guarantee when the destructor will be
called.
Hope this helps.
(1) Any code using pointers cannot be 'managed' by CLR. So you've to put it
in 'unsafe' block.
(2) Any object in a program's memory can be garbage collected or moved to a
different location in memory without any notice by the garbage collector of
..NET runtime. To fix a pointer and memory pointed to by the pointer in
memory, you've to use 'fixed' clause. Any pointer declared inside a 'fixed'
expression will be pinned in memory and will not be moved by the GC.
(3) Any value types declared within an 'unsafe' block are automatically
treated as 'fixed' by the runtime and so these cannot appear within a 'fixed'
clause.
(4) As a guideline for use of pointers, you'll have to use them only when
execution speed is utmost important, or you've to call some Windows API
function which requires a pointer as a parameter.
About Destructors in C#:
(1) In general you don't need to worry about freeing memory. However when
your application encapsulates unmanaged resources such as windows, files, and
network connections, you should use destructors to free those resources.
(2) Destructor is called by the GC AFTER an object is marked for
destruction, that is when it is no longer refernced or it is no longer in
scope.
(3) The destructor implicitly calls the Object.Finalize() method.
(4) Destructors cannot be invoked explicitly. They cannot be inherited and
overloaded.
(5) Structs do not have destructors
(6) In general it's better to implement Dispose() method of IDisposable
interface and put the clean up code there, and call it whenever the object is
to be destroyed, because there is no guarantee when the destructor will be
called.
Hope this helps.
A
Akhil
Thanks a lot Sameeksha......that led to lot of clarity.
G
Guest
there are a lot of misinformation in this post that needs to be corrected.
see inline
the wording of this seems somewhat misleading. to use pointers in a method
or a class, you need mark them unsafe, but it doesn't mean that CLR
completely ignores these blocks. in fact, the second point shows that they
are still very much affected by the CLR.
this only applies to managed heap.
unsafe keyword doesn't intrinsically pin anything. the reason local
variables doesn't need to be fixed is because it's located on the stack, and
the stack is not subject to the GC.
this is an area I feel that the doc is very misleading. there is no
destructor in .NET. C# uses the C destructor syntax to express
Object.Finalize(), but it's not really a destructor.
actually, it's better to implement both. you should definitely implement
Dispose to free resource on demand. but you also need Finalize as a fail
safe in case Dispose wasn't called by the programmer. otherwise, you are
leaking resource.
the doc is being overly cautious when saying Finalizers are not guarantteed
to be called. in fact, Finalizers are guarantteed to be called as long as
your program doesn't terminate abnormally, meaning it didn't crash the
runtime, got into a deadlock or any other situation that forces you to kill
the process prematurely. In fact, I'd be very worried if it doesn't <em>at
see inline
Sameeksha said:There are a few things to be considered about pointers in C#:
(1) Any code using pointers cannot be 'managed' by CLR. So you've to put it
in 'unsafe' block.
the wording of this seems somewhat misleading. to use pointers in a method
or a class, you need mark them unsafe, but it doesn't mean that CLR
completely ignores these blocks. in fact, the second point shows that they
are still very much affected by the CLR.
(2) Any object in a program's memory can be garbage collected or moved to a
different location in memory without any notice by the garbage collector of
.NET runtime. To fix a pointer and memory pointed to by the pointer in
memory, you've to use 'fixed' clause. Any pointer declared inside a 'fixed'
expression will be pinned in memory and will not be moved by the GC.
this only applies to managed heap.
(3) Any value types declared within an 'unsafe' block are automatically
treated as 'fixed' by the runtime and so these cannot appear within a 'fixed'
clause.
unsafe keyword doesn't intrinsically pin anything. the reason local
variables doesn't need to be fixed is because it's located on the stack, and
the stack is not subject to the GC.
(4) As a guideline for use of pointers, you'll have to use them only when
execution speed is utmost important, or you've to call some Windows API
function which requires a pointer as a parameter.
About Destructors in C#:
this is an area I feel that the doc is very misleading. there is no
destructor in .NET. C# uses the C destructor syntax to express
Object.Finalize(), but it's not really a destructor.
(1) In general you don't need to worry about freeing memory. However when
your application encapsulates unmanaged resources such as windows, files, and
network connections, you should use destructors to free those resources.
(2) Destructor is called by the GC AFTER an object is marked for
destruction, that is when it is no longer refernced or it is no longer in
scope.
(3) The destructor implicitly calls the Object.Finalize() method.
(4) Destructors cannot be invoked explicitly. They cannot be inherited and
overloaded.
(5) Structs do not have destructors
(6) In general it's better to implement Dispose() method of IDisposable
interface and put the clean up code there, and call it whenever the object is
to be destroyed, because there is no guarantee when the destructor will be
called.
actually, it's better to implement both. you should definitely implement
Dispose to free resource on demand. but you also need Finalize as a fail
safe in case Dispose wasn't called by the programmer. otherwise, you are
leaking resource.
the doc is being overly cautious when saying Finalizers are not guarantteed
to be called. in fact, Finalizers are guarantteed to be called as long as
your program doesn't terminate abnormally, meaning it didn't crash the
runtime, got into a deadlock or any other situation that forces you to kill
the process prematurely. In fact, I'd be very worried if it doesn't <em>at
C
Chris Lyon [MSFT]
Daniel Jin is correct, there is a lot of misinformation. I'll try to clear up any that Daniel missed...
First of all, there are no destructors in C#. There are finalizers which are expressed using C++'s destructor syntax. After the Garbage Collector collects your dead reference
object (no more live references to it), if it implements a finalizer, it is put on the finalization queue and run at an undetermined time in the future by the GC's finalization thread.
Daniel is correct. Please see the Dispose pattern:
http://msdn.microsoft.com/library/d.../en-us/cpgenref/html/cpconfinalizedispose.asp
Note it's also a good idea to suppress the finalizer upon successful completion of Dispose, to avoid double freeing resources, and to avoid putting your object ont he
finalization queue, which is expensive, since it is promoted a generation, as are any objects it references.
Actually, there are other cases when a finalizer may not be run:
-When the appdomain that contains the object is "rudely" unloaded
-There is a finalizer that is starving the finalizers by hogging the finalizer thread (which has a timeout)
-The finalizer thread times out because of too many finalizable objects on the queue.
Don't worry thoug, when the CLR shuts down, unmanaged resources will be released, but buffers may not be flushed, and final writes may be lost.
Hope that helps!
-Chris
--
This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they originated.
First of all, there are no destructors in C#. There are finalizers which are expressed using C++'s destructor syntax. After the Garbage Collector collects your dead reference
object (no more live references to it), if it implements a finalizer, it is put on the finalization queue and run at an undetermined time in the future by the GC's finalization thread.
actually, it's better to implement both. you should definitely implement
Dispose to free resource on demand. but you also need Finalize as a fail
safe in case Dispose wasn't called by the programmer. otherwise, you are
leaking resource.
Daniel is correct. Please see the Dispose pattern:
http://msdn.microsoft.com/library/d.../en-us/cpgenref/html/cpconfinalizedispose.asp
Note it's also a good idea to suppress the finalizer upon successful completion of Dispose, to avoid double freeing resources, and to avoid putting your object ont he
finalization queue, which is expensive, since it is promoted a generation, as are any objects it references.
the doc is being overly cautious when saying Finalizers are not guarantteed
to be called. in fact, Finalizers are guarantteed to be called as long as
your program doesn't terminate abnormally, meaning it didn't crash the
runtime, got into a deadlock or any other situation that forces you to kill
the process prematurely. In fact, I'd be very worried if it doesn't <em>at
least</em> guaranttee me that resources will be freed when I close my
application, that'd be a terrible platform.
Actually, there are other cases when a finalizer may not be run:
-When the appdomain that contains the object is "rudely" unloaded
-There is a finalizer that is starving the finalizers by hogging the finalizer thread (which has a timeout)
-The finalizer thread times out because of too many finalizable objects on the queue.
Don't worry thoug, when the CLR shuts down, unmanaged resources will be released, but buffers may not be flushed, and final writes may be lost.
Hope that helps!
-Chris
there are a lot of misinformation in this post that needs to be corrected.
see inline
the wording of this seems somewhat misleading. to use pointers in a method
or a class, you need mark them unsafe, but it doesn't mean that CLR
completely ignores these blocks. in fact, the second point shows that they
are still very much affected by the CLR.
this only applies to managed heap.
unsafe keyword doesn't intrinsically pin anything. the reason local
variables doesn't need to be fixed is because it's located on the stack, and
the stack is not subject to the GC.
this is an area I feel that the doc is very misleading. there is no
destructor in .NET. C# uses the C destructor syntax to express
Object.Finalize(), but it's not really a destructor.
actually, it's better to implement both. you should definitely implement
Dispose to free resource on demand. but you also need Finalize as a fail
safe in case Dispose wasn't called by the programmer. otherwise, you are
leaking resource.
the doc is being overly cautious when saying Finalizers are not guarantteed
to be called. in fact, Finalizers are guarantteed to be called as long as
your program doesn't terminate abnormally, meaning it didn't crash the
runtime, got into a deadlock or any other situation that forces you to kill
the process prematurely. In fact, I'd be very worried if it doesn't <em>at
--
This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they originated.
G
Guest
Actually, there are other cases when a finalizer may not be run:
-When the appdomain that contains the object is "rudely" unloaded
-There is a finalizer that is starving the finalizers by hogging the finalizer thread (which has a timeout)
-The finalizer thread times out because of too many finalizable objects on the queue.
interesting. I wasn't aware of the last two points. I guess the doc was
right in the cautious approach. more reason not to rely on finalizers too
much. thanks for the information.
is there a reason why there's a timeout on the finalization thread? is it
to avoid a hanging finalizer, like one that is in a deadlock.
Don't worry thoug, when the CLR shuts down, unmanaged resources will be released, but buffers may not be flushed, and final writes may be lost.
good to know nothing is leaked permanently. I can sleep better now.
B
bob holder
Daniel Jin said:on the queue.
interesting. I wasn't aware of the last two points. I guess the doc was
right in the cautious approach. more reason not to rely on finalizers too
much. thanks for the information.
is there a reason why there's a timeout on the finalization thread? is it
to avoid a hanging finalizer, like one that is in a deadlock.
Exactly. Good example in the August msdnmag .NET Matters column.
good to know nothing is leaked permanently. I can sleep better now.
Everything is still under control of the OS. This has been the case for
Win32 processes since NT3.1, and .NET apps pick it up as well for system
resources.
bob