Using "using"
-
I've seen a lot of code that looks something like the following:
using (using (FileStream fs = new FileStream(path, FileMode.Create, FileAccess.ReadWrite, FileShare.None))
I realize that this ensures that everything will be properly closed and disposed without you having to do anything, but doesn't the same thing happen when the object goes out of scope? Further, what about exception handling? Is that automatically handled as well? Is it wrong to not want to sue this construct in favor of more obvious code?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John using is a convenience that hides the following pattern:
FileStream fs = null;
try
{
fs = new FileStream(path, FileMode.Create, FileAccess.ReadWrite, FileShare.None);
}
finally
{
((IDisposable)fs).Dispose();
}Basically, this guarantees that the Dispose method is called regardless of whether an exception happens or not, thus freeing up unmanaged resources in this case. If a class has a Dispose method, then it should always be called because (presumably) the developers have identified that particular items have to be freed up probably because they are expensive to maintain. The added bonus here is that most implementations of Dispose call
GC.SuppressFinalize(...);so the finalizer (if any) is suppressed.Deja View - the feeling that you've seen this post before.
-
I've seen a lot of code that looks something like the following:
using (using (FileStream fs = new FileStream(path, FileMode.Create, FileAccess.ReadWrite, FileShare.None))
I realize that this ensures that everything will be properly closed and disposed without you having to do anything, but doesn't the same thing happen when the object goes out of scope? Further, what about exception handling? Is that automatically handled as well? Is it wrong to not want to sue this construct in favor of more obvious code?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
using (using (FileStream fs = new FileStream(path, FileMode.Create, FileAccess.ReadWrite, FileShare.None))
I think this statement is wrong. You can use nested
usingstatements in this wayusing(DisposableObject1)
using(DisposableObject2)
{
}John Simmons / outlaw programmer wrote:
but doesn't the same thing happen when the object goes out of scope?
Do you mean it will be disposed when the scope ends ? GC will handle it, but there would be a delay in disposal. This will produce same IL which try/finally is producing. So it's just a syntactic shortcut to call
Dispose()method which ensures immediate disposal.All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions
-
John using is a convenience that hides the following pattern:
FileStream fs = null;
try
{
fs = new FileStream(path, FileMode.Create, FileAccess.ReadWrite, FileShare.None);
}
finally
{
((IDisposable)fs).Dispose();
}Basically, this guarantees that the Dispose method is called regardless of whether an exception happens or not, thus freeing up unmanaged resources in this case. If a class has a Dispose method, then it should always be called because (presumably) the developers have identified that particular items have to be freed up probably because they are expensive to maintain. The added bonus here is that most implementations of Dispose call
GC.SuppressFinalize(...);so the finalizer (if any) is suppressed.Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
((IDisposable)fs).Dispose();
Just wondering why this cast ?
fs.Dispose()will do it, Right ?All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions
-
I've seen a lot of code that looks something like the following:
using (using (FileStream fs = new FileStream(path, FileMode.Create, FileAccess.ReadWrite, FileShare.None))
I realize that this ensures that everything will be properly closed and disposed without you having to do anything, but doesn't the same thing happen when the object goes out of scope? Further, what about exception handling? Is that automatically handled as well? Is it wrong to not want to sue this construct in favor of more obvious code?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
but doesn't the same thing happen when the object goes out of scope?
Yes but garbage collection is non-deterministic and
usingoffers deterministic resource clean up. I'm just the messenger, don't shoot me!led mike
-
I've seen a lot of code that looks something like the following:
using (using (FileStream fs = new FileStream(path, FileMode.Create, FileAccess.ReadWrite, FileShare.None))
I realize that this ensures that everything will be properly closed and disposed without you having to do anything, but doesn't the same thing happen when the object goes out of scope? Further, what about exception handling? Is that automatically handled as well? Is it wrong to not want to sue this construct in favor of more obvious code?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
I realize that this ensures that everything will be properly closed and disposed without you having to do anything, but doesn't the same thing happen when the object goes out of scope?
No, it doesn't. The memory management doesn't use reference counting, which means that nothing happens because of an object going out of scope. Because there is no possibility to add any code that will run when the object goes out of scope, the IDisposable interface was created, so that the lifetime of an object could be controlled from the code. Ordinary objects that doesn't have a specific need for any cleanup, doesn't have a Dispose method. They will just be removed when the garbage collector notices that the can be.
Despite everything, the person most likely to be fooling you next is yourself.
-
John using is a convenience that hides the following pattern:
FileStream fs = null;
try
{
fs = new FileStream(path, FileMode.Create, FileAccess.ReadWrite, FileShare.None);
}
finally
{
((IDisposable)fs).Dispose();
}Basically, this guarantees that the Dispose method is called regardless of whether an exception happens or not, thus freeing up unmanaged resources in this case. If a class has a Dispose method, then it should always be called because (presumably) the developers have identified that particular items have to be freed up probably because they are expensive to maintain. The added bonus here is that most implementations of Dispose call
GC.SuppressFinalize(...);so the finalizer (if any) is suppressed.Deja View - the feeling that you've seen this post before.
Nitpicking here, but you forgot
if (fs != null):). The finally block looks likeif (fs != null)
((IDisposable)fs).Dispose();Regards Senthil [MVP - Visual C#] _____________________________ My Blog | My Articles | My Flickr | WinMacro
-
John using is a convenience that hides the following pattern:
FileStream fs = null;
try
{
fs = new FileStream(path, FileMode.Create, FileAccess.ReadWrite, FileShare.None);
}
finally
{
((IDisposable)fs).Dispose();
}Basically, this guarantees that the Dispose method is called regardless of whether an exception happens or not, thus freeing up unmanaged resources in this case. If a class has a Dispose method, then it should always be called because (presumably) the developers have identified that particular items have to be freed up probably because they are expensive to maintain. The added bonus here is that most implementations of Dispose call
GC.SuppressFinalize(...);so the finalizer (if any) is suppressed.Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
because (presumably) the developers have identified that particular items have to be freed up probably because they are expensive to maintain.
Great. And isn't this very similar to responsibility for memory allocation and freeing that makes a Garbage Collection environment so desirable? :rolleyes: I mean you'd think a VB developer that can actually understand the Dispose Pattern could handle new and delete. I'm just saying... :-\
led mike
-
Pete O'Hanlon wrote:
((IDisposable)fs).Dispose();
Just wondering why this cast ?
fs.Dispose()will do it, Right ?All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions
The object will be freed, but any unmanaged resources will linger unless freed up. Implementing the IDisposable interface is the recommended way to do that. And as someone mentioned using is just a shorthand way to call it safely. Eventually the garbage collector will collect the object; however, that doesn't necessarily free resources. The finalizer will be called unless suppressed, but that will only call Dispose if you specifically do so in your finalizer code.
N a v a n e e t h wrote:
Just wondering why this cast ? fs.Dispose() will do it, Right ?
The object may not directly implement the interface, but may have explictly implemented it. In that case its necessary to cast the object to IDisposable.
-
I've seen a lot of code that looks something like the following:
using (using (FileStream fs = new FileStream(path, FileMode.Create, FileAccess.ReadWrite, FileShare.None))
I realize that this ensures that everything will be properly closed and disposed without you having to do anything, but doesn't the same thing happen when the object goes out of scope? Further, what about exception handling? Is that automatically handled as well? Is it wrong to not want to sue this construct in favor of more obvious code?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
I realize that this ensures that everything will be properly closed and disposed without you having to do anything, but doesn't the same thing happen when the object goes out of scope?
Not when the object goes out of scope, but when the GC runs and that too only if the object has a finalizer. Garbage collection cleans up the object itself; it doesn't attempt to clean up any resources held by the object. IDisposable (and the finalizer) do the resource cleanup part.
Regards Senthil [MVP - Visual C#] _____________________________ My Blog | My Articles | My Flickr | WinMacro
-
The object will be freed, but any unmanaged resources will linger unless freed up. Implementing the IDisposable interface is the recommended way to do that. And as someone mentioned using is just a shorthand way to call it safely. Eventually the garbage collector will collect the object; however, that doesn't necessarily free resources. The finalizer will be called unless suppressed, but that will only call Dispose if you specifically do so in your finalizer code.
N a v a n e e t h wrote:
Just wondering why this cast ? fs.Dispose() will do it, Right ?
The object may not directly implement the interface, but may have explictly implemented it. In that case its necessary to cast the object to IDisposable.
tgrt wrote:
The object may not directly implement the interface
Did you mean "implicitly"? Both implicit and explicit implimentations are direct, surely?
Upcoming FREE developer events: * Developer Day Scotland Recent blog posts: * Introduction to LINQ to XML (Part 1) - (Part 2) My website | Blog
-
I've seen a lot of code that looks something like the following:
using (using (FileStream fs = new FileStream(path, FileMode.Create, FileAccess.ReadWrite, FileShare.None))
I realize that this ensures that everything will be properly closed and disposed without you having to do anything, but doesn't the same thing happen when the object goes out of scope? Further, what about exception handling? Is that automatically handled as well? Is it wrong to not want to sue this construct in favor of more obvious code?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001See http://www.codeproject.com/KB/cs/tinguusingstatement.aspx[^]
John Simmons / outlaw programmer wrote:
Is it wrong to not want to sue this construct in favor of more obvious code?
Do you want to type out all the try-finally-dispose things again and again, or understand
usingonce and save the typing (AND reading)? edit: omfg, it took me 30min to write this and find a link :~ there wasnt any replies when i started typing...
[My Blog]
"Visual studio desperately needs some performance improvements. It is sometimes almost as slow as eclipse." - Rüdiger Klaehn
"Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfe -
tgrt wrote:
The object may not directly implement the interface
Did you mean "implicitly"? Both implicit and explicit implimentations are direct, surely?
Upcoming FREE developer events: * Developer Day Scotland Recent blog posts: * Introduction to LINQ to XML (Part 1) - (Part 2) My website | Blog
-
I've seen a lot of code that looks something like the following:
using (using (FileStream fs = new FileStream(path, FileMode.Create, FileAccess.ReadWrite, FileShare.None))
I realize that this ensures that everything will be properly closed and disposed without you having to do anything, but doesn't the same thing happen when the object goes out of scope? Further, what about exception handling? Is that automatically handled as well? Is it wrong to not want to sue this construct in favor of more obvious code?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001What's with the extra
using (? -
John Simmons / outlaw programmer wrote:
but doesn't the same thing happen when the object goes out of scope?
Yes but garbage collection is non-deterministic and
usingoffers deterministic resource clean up. I'm just the messenger, don't shoot me!led mike
GC and dispose are also doing different stuff. GC frees the memory allocated by the managed object. Dispose is supposed to release native resources allocated by an object. So even if you call dispose, the managed object is still present untill it gets eaten by the GC.
Blog: http://www.rogeralsing.com Projects: http://www.puzzleframework.com
-
John Simmons / outlaw programmer wrote:
I realize that this ensures that everything will be properly closed and disposed without you having to do anything, but doesn't the same thing happen when the object goes out of scope?
No, it doesn't. The memory management doesn't use reference counting, which means that nothing happens because of an object going out of scope. Because there is no possibility to add any code that will run when the object goes out of scope, the IDisposable interface was created, so that the lifetime of an object could be controlled from the code. Ordinary objects that doesn't have a specific need for any cleanup, doesn't have a Dispose method. They will just be removed when the garbage collector notices that the can be.
Despite everything, the person most likely to be fooling you next is yourself.
>>so that the lifetime of an object could be controlled from the code. rather: Lifetime of resources used by an object could be controlled from the code. The disposable object itself will not be removed from memory when you call dispose on it..
Blog: http://www.rogeralsing.com Projects: http://www.puzzleframework.com
-
Nitpicking here, but you forgot
if (fs != null):). The finally block looks likeif (fs != null)
((IDisposable)fs).Dispose();Regards Senthil [MVP - Visual C#] _____________________________ My Blog | My Articles | My Flickr | WinMacro
Spot on. Sorry and all that. ;)
Deja View - the feeling that you've seen this post before.
-
See http://www.codeproject.com/KB/cs/tinguusingstatement.aspx[^]
John Simmons / outlaw programmer wrote:
Is it wrong to not want to sue this construct in favor of more obvious code?
Do you want to type out all the try-finally-dispose things again and again, or understand
usingonce and save the typing (AND reading)? edit: omfg, it took me 30min to write this and find a link :~ there wasnt any replies when i started typing...
[My Blog]
"Visual studio desperately needs some performance improvements. It is sometimes almost as slow as eclipse." - Rüdiger Klaehn
"Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfednh wrote:
edit: omfg, it took me 30min to write this and find a link there wasnt any replies when i started typing...
Sorry - I just typed my answer from memory which was why I missed a null check. ;)
Deja View - the feeling that you've seen this post before.
-
>>so that the lifetime of an object could be controlled from the code. rather: Lifetime of resources used by an object could be controlled from the code. The disposable object itself will not be removed from memory when you call dispose on it..
Blog: http://www.rogeralsing.com Projects: http://www.puzzleframework.com
Roger Alsing wrote:
rather: Lifetime of resources used by an object could be controlled from the code.
Good point. I should have said that it's for controlling the life cycle of the object rather than the lifetime.
Despite everything, the person most likely to be fooling you next is yourself.
-
What's with the extra
using (?Wasn't this the OP's question?
-Spacix All your skynet questions[^] belong to solved
I dislike the black-and-white voting system on questions/answers. X|
-
Wasn't this the OP's question?
-Spacix All your skynet questions[^] belong to solved
I dislike the black-and-white voting system on questions/answers. X|
I can't tell.
