Develop Reference

Disposable wrapped in a using statement, object is added to list but can still be accessed via the list from outside of the using statement. why? [duplicate]

Is it legal to call a method on disposed object? If yes, why?
In the following demo program, I've a disposable class A (which implements IDisposable interface).As far as I know, if I pass disposable object to using() construct, then Dispose() method gets called automatically at the closing bracket:
A a = new A();
using (a)
{
//...
}//<--------- a.Dispose() gets called here!
//here the object is supposed to be disposed,
//and shouldn't be used, as far as I understand.
If that is correct, then please explain the output of this program:
public class A : IDisposable
{
int i = 100;
public void Dispose()
{
Console.WriteLine("Dispose() called");
}
public void f()
{
Console.WriteLine("{0}", i); i *= 2;
}
}
public class Test
{
public static void Main()
{
A a = new A();
Console.WriteLine("Before using()");
a.f();
using ( a)
{
Console.WriteLine("Inside using()");
a.f();
}
Console.WriteLine("After using()");
a.f();
}
}
Output (ideone):
Before using()
100
Inside using()
200
Dispose() called
After using()
400
How can I call f() on the disposed object a? Is this allowed? If yes, then why? If no, then why the above program doesn't give exception at runtime?
I know that the popular construct of using using is this:
using (A a = new A())
{
//working with a
}
But I'm just experimenting, that is why I wrote it differently.

Disposed doesn't mean gone. Disposed only means that any unmanaged resource (like a file, connection of any kind, ...) has been released. While this usually means that the object doesn't provide any useful functionality, there might still be methods that don't depend on that unmanaged resource and still work as usual.
The Disposing mechanism exist as .net (and inheritly, C#.net) is a garbage-collected environment, meaning you aren't responsable for memory management. However, the garbage collector can't decide if an unmanaged resource has been finished using, thus you need to do this yourself.
If you want methods to throw an exception after the object has been diposed, you'll need a boolean to capture the dispose status, and once the object is disposed, you throw the exception:
public class A : IDisposable
{
int i = 100;
bool disposed = false;
public void Dispose()
{
disposed = true;
Console.WriteLine("Dispose() called");
}
public void f()
{
if(disposed)
throw new ObjectDisposedException();
Console.WriteLine("{0}", i); i *= 2;
}
}

The exception is not thrown because you have not designed the methods to throw ObjectDisposedException after Dispose has been called.
The clr does not automagically know that it should throw ObjectDisposedException once Dispose is called. It's your responsibility to throw an exception if Dispose has released any resources needed for successful execution of your methods.

A typical Dispose() implementation only calls Dispose() on any objects that it stores in its fields that are disposable. Which in turn release unmanaged resources. If you implement IDisposable and not actually do anything, like you did in your snippet, then the object state doesn't change at all. Nothing can go wrong. Don't mix up disposal with finalization.

The purpose of IDisposable is to allow an object to fix the state of any outside entities which have, for its benefit, been put into a state that is less than ideal for other purposes. For example, an Io.Ports.SerialPort object might have changed the state of a serial port from "available for any application that wants it" to "only usable by one particular Io.Ports.SerialPort object"; the primary purpose of SerialPort.Dispose is to restore the state of the serial port to "available for any application".
Of course, once an object that implements IDisposable has reset entities that had been maintaining a certain state for its benefit, it will no longer have the benefit of those entities' maintained state. For example, once the state of the serial port has been set to "available for any application", the data streams with which it had been associated can no longer be used to send and receive data. If an object could function normally without outside entities being put into a special state for its benefit, there would be no reason to leave outside entities in a special state in the first place.
Generally, after IDisposable.Dispose has been called on an object, the object should not be expected to be capable of doing much. Attempting to use most methods on such an object would indicate a bug; if a method can't reasonably be expected to work, the proper way to indicate that is via ObjectDisposedException.
Microsoft suggests that nearly all methods on an object which implements IDisposable should throw ObjectDisposedException if they are used on an object which has been disposed. I would suggest that such advice is overbroad. It is often very useful for devices to expose methods or properties to find out what happened while the object was alive. Although one could give a communications class a Close method as well as a Dispose method, and only allow one to query things like NumberOfPacketsExchanged after a close but not after a Dispose, but that seems excessively complicated. Reading properties related to things that happened before an object was Disposed seems a perfectly reasonable pattern.

Calling Dispose() doesn't set the object reference to null, and your custom disposable class doesn't contain any logic to throw an exception if its functions are accessed after Dispose() has been called so it is of course legal.
In the real world, Dispose() releases unmanaged resources and those resources will be unavailable thereafter, and/or the class author has it throw ObjectDisposedException if you try to use the object after calling Dispose(). Typically a class-level boolean would be set to true within the body of Dispose() and that value checked in the other members of the class before they do any work, with the exception being thrown if the bool is true.

A disposer in C# is not the same as a destructor in C++. A disposer is used to release managed (or unmanaged) resources while the object remains valid.
Exceptions are thrown depending on the implementation of the class. If f() does not require the use of your already disposed objects, then it doesn't necessarily need to throw an exception.

How to dispose object

How to dispose my object? I am doing it by this. Whats is wrong? The Obj.Dispose() function does not appear to be right.
class MainclassForm : Form, IDisposeable
{
public void createanddispose()
{
A obj = new A();
obj.dowork();
obj.Dispose();//does not appear as a function
}
}

You can better use the using statement. Something like
using (MyIDisposableObject obj = new MyIDisposableObject())
{
// object here
}
A good reference to check on MSDN: Avoiding Problems with the Using Statement
The C# "using" statement results in a call to Dispose(). This is the
same as Close(), which may throw exceptions when a network error
occurs. Because the call to Dispose() happens implicitly at the
closing brace of the "using" block, this source of exceptions is
likely to go unnoticed both by people writing the code and reading the
code. This represents a potential source of application errors.

To call Dispose() on an object, your class must be inherited from IDisposeable interface and have an implementation of it:
class A : IDisposable
{
public void Dispose()
{
GC.Collect();
}
}

There are a couple things wrong here, but I believe the root is that you might confusing IDisposable with a Garbage Collector.
IDisposable is an interface that the type A, in your example, may implement. It that were the case, you could be sure that any instance of A had the method Dispose() you're looking for. This is useful for things like Streams, where they need to be closed, but it's not useful for (just as an example) a ComplexNumber type that has no outstanding resources.
In these cases, your managed C# code will handle all the "disposal" that needs to happen. It will get rid of the memory that object is using. That feature comes for free (sort of), and you don't need (or want) to do anything to explicitly invoke it. That's the main difference between managed (C#, Java, etc.) and unmanaged (C++) code.
Essentially, if an object is using more than just memory (like an open file does), IDisposable will be useful. If it is just memory (like a Form, or DateTime, or a majority of other things), there's no need for it.
As for your specific code, you've applied IDisposable to the type that contains your functions. Just as you couldn't call this.AddMinutes(1) to get at DateTime's method, you can't get at this one.
If you do need the added functionality of implementing IDisposable, you'll have to do it on A. Applying IDisposable, like any other interface, to MainclassForm will tell the compiler that you have a Dispose() method on that class, which is true only because the Windows Forms object has one. If it didn't, this would throw a compiler error, and you'd have to add one.

Why using Dispose as a normal method is bad?

Trying to figure it out. Someone told me
Dispose is not just a method - it's equivalent to a destructor in other languages.
Ok. Msdn is also very loud about this.
But then
class Test : IDisposable
{
public string Property { get; set; } = "Test";
public void Dispose() => Console.WriteLine("Disposed, very scary");
}
class Program
{
static void Main(string[] args)
{
var test = new Test();
test.Dispose();
test.Property = "123"; // but it's disposed OMG! do not do this!
test.Dispose();
using (var another = new Test())
for (int i = 0; i < 10; i++)
{
another.Dispose();
GC.Collect(); // or what should I call to make it crash?
}
Console.ReadKey();
}
}
And there are no problems.
What I think about Dispose:
it's a normal public method;
IDisposable is useful in conjunction with using to automatically call Dispose, nothing more;
it's totally fine to put into dispose any code an call it internally at any time if object state properly maintained.
Correct me if I am wrong.
P.S: Downvote means "question is bad/not useful/has problem". If you simply disagree with my thoughts - post comment or answer. It will be useful for people who think as I do right now (because I am wrong? then prove it)

Dispose is just a method, you can call it just like any other method. It is always exposed through the IDisposable interface (yes, obviously you can name a method Dispose without implementing IDisposable, don't do that!).
However, calling it manually is sometimes a code smell, smell of code that should probably be using using instead. By "manually" here I mean calling Dispose outside of the implementation of another Dispose.
Calling it twice should also be safe and is documented:
If an object's Dispose method is called more than once, the object must ignore all calls after the first one. The object must not throw an exception if its Dispose method is called multiple times. Instance methods other than Dispose can throw an ObjectDisposedException when resources are already disposed.
(my emphasis)
Should you be calling Dispose twice? No!. That is also a code smell of code that no longer has control of what it has done and what it has left to do and ends up doing things "just to be sure". Don't do that either!
So if you write code correctly, sure you can call Dispose manually.

You're right, Dispose is just another method, belonging to IDisposable. It just has the added benefit of being able to be automatically called when a using() scope ends - it is not equivalent to a destructor and whoever told you that doesn't truly understand what they're saying.
I'd always use a using() block where possible, but if you're careful you can manually call Dispose instead and it will have the same effect.

Visual Studio 2015 offers up (finally) a suggested pattern for implementation of IDisposable which matches the guidelines.
This is the stub that VS creates for you when selecting to implement the disposable pattern. The TODOs guide us through the implementation.
class Disposable : IDisposable
{
#region IDisposable Support
private bool disposedValue = false; // To detect redundant calls
protected virtual void Dispose(bool disposing)
{
if (!disposedValue)
{
if (disposing)
{
// TODO: dispose managed state (managed objects).
}
// TODO: free unmanaged resources (unmanaged objects) and override a finalizer below.
// TODO: set large fields to null.
disposedValue = true;
}
}
// TODO: override a finalizer only if Dispose(bool disposing) above has code to free unmanaged resources.
// ~Disposable() {
// // Do not change this code. Put cleanup code in Dispose(bool disposing) above.
// Dispose(false);
// }
// This code added to correctly implement the disposable pattern.
public void Dispose()
{
// Do not change this code. Put cleanup code in Dispose(bool disposing) above.
Dispose(true);
// TODO: uncomment the following line if the finalizer is overridden above.
// GC.SuppressFinalize(this);
}
#endregion
}
Note the use of a flag to indicate if the Dispose has already been called. This flag can be used to throw ObjectDisposedException instances on method calls and properties across the classes implementation.
The intention of Dispose has always been to clean up unmanaged resources. However, the syntactic sugar of the using keyword (requires an IDisposable) lets you create really tidy 'context' pattern classes for managing resource access, even if there are no unmanaged resources used.
As usual, document the usage and the intentions clearly and you can't go wrong but please avoid methods called 'Dispose' if you don't implement the interface.

There is a critical difference between Dispose in .NET versus destructors in other languages: if one has a pointer to an object in another language and the object is deleted, one will have an invalid pointer and there is no way to do anything with it, including determine whether it is still valid, without invoking Undefined Behavior. By contrast, in .NET if one has a reference to an object which gets Disposed, the reference will continue to be a valid reference to the object in question. The object will likely refuse to do much because it's been disposed, but such refusal is affirmatively generated by the object itself. No Undefined Behavior involved.
On the flip side, when a destructor is invoked in other languages like C++ an object can be certain that no valid pointers exist to it anymore, but that is not true of Dispose. Consequently, code should avoid pooling public-facing objects and instead have every request for a new object return a new object (which may be a wrapper to a pooled object). If no reference to the pooled object exists outside the wrapper, and Dispose invalidates that reference before returning the object to the pool, then a future object request can be satisfied by encapsulating the pooled object in a new wrapper which will again hold the only reference to it.

When does the Dispose Method get called? [duplicate]

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
IDisposable Question
I have written a class and implemented the IDisposable interface.
I implemetned the Dispose method and put a Code Break in the method.
My assumption is it would have been called when the Class went out of scope due to C# Garabage collection.
I want the dispose method to close an unmanaged resource. I thought it would be more elegant than just calling the method LogOff() instead getting it called whenever the method went out of scope?
But it doesn't seem to get called or stop at the code break.

You need to explicitly call Dispose on any objects that implement IDisposable. If you use the using() {} code construct the compiler will automatically call Dispose at the end of the using block.
A good pattern is to also track via a private boolean field whether dispose has been called or not, and if not call it from the objects finalizer (and also call GC.SuppressFinalize() from your Dispose method assuming that you handle all finalization tasks from there also).

You should consider wrapping your interaction with your IDisposable class in a using statement. Doing so will allow you to specify when your object goes out of scope, and ensures the Dispose() method gets called.
For the correct syntax, see the example from the referenced MSDN article:
using System;
class C : IDisposable
{
public void UseLimitedResource()
{
Console.WriteLine("Using limited resource...");
}
void IDisposable.Dispose()
{
Console.WriteLine("Disposing limited resource.");
}
}
class Program
{
static void Main()
{
using (C c = new C())
{
c.UseLimitedResource();
}
Console.WriteLine("Now outside using statement.");
Console.ReadLine();
}
}

Short answer: Dispose() is called when you call it.
Long answer: take a look at using block. This is a syntax sugar that meant to be used together with IDisposable interface for pretty and safely disposing code, and is roughly equivalent to
Foo foo = new Foo();
try
{
// your code that uses foo
}
finally
{
foo.Dispose();
}
In other words foo is guaranteed to be disposed upon leaving using() scope.

Garbage collection does not happen immediately after a variable goes out of scope. The GC runs periodically and .NET has different "levels" of Garbage collection. Different levels get collected more frequently. If you want your object's dispose method to be called immediately, you should use a using statement
using (MyClass object = new MyClass())
{
//ensures Dipose is called, even if exceptions are thrown
}

My assumption is it would have been called when the Class went out of scope due to C# Garabage collection.
That's now how garbage collection works. There's two things going on here:
Garbage collection - this cleans up objects at some time after there's no longer any references left to them. This implies that the objects have gone out of scope (if they are locals), but notably GC doesn't say when this cleanup happens - it usually happens lazily when the system decides it needs to run a collection to free up more memory. The method that is called to clean up resources in this case is the finalizer, which in C# has the form ~Classname().
IDisposable: the problem with GC is that you have no control over when the finalizer is called, so IDisposable was introduced as a pattern to be used when you need resources to be cleaned up at a specific time and don't want to wait for a collect to happen. It's up to the caller code to call Dispose() as appropriate, there's no GC support. C# does have the using(){} syntax, which simplifies this, and calls Dispose() automatically at the end of the using block.

Will object with reference kept be disposed?

May I know if the "objectToBeDisposed" will be disposed if its reference are kept by the "useDisposableObject"?
using(IDisposable objectToBeDisposed = new ObjectImplementedIDisposable ()){
ChildObject useDisposableObject = new ChildObject(objectToBeDisposed);
.... doing stuff with useDisposableObject;
}

Yes, in your example it will be disposed, because the using block explicitly calls the Dispose() method when leaving that block.
As an aside the referencing object is within the using block scope and will go out of scope at the end of the using block, which will avoid the potential issue of accessing a disposed object if the referencing object tried to use it once it was disposed.
Update thanks to #dlev

Disposal, finalization and memory deallocation are 3 totally different things in the .NET world.
Disposal is only an "application logic" thing, it is implemented through the disposable pattern.
If you implement the interface IDisposable, your object can be used with the using keyword.
The using keyword will translate in a simple way:
using (IDisposable xxx = new MyObject())
{
....
}
means
{
IDisposable xxx = new MyObject();
try
{
....
}
finally
{
if (xxx != null)
xxx.Dispose();
}
}
There is no other magic in this. That's all.
Object finalization is instead called by garbage collector when the objects should be freed.
The time when it happens and the order between destructors is unpredictable.
class myclass { ~myclass() { this code will be called by garbage collector, i cannot call it } }
The syntax is very similar to C++ destructors but the meaning is a lot different.
And then memory deallocation.
Memory deallocation is not connected to object disposal!
You can keep forever a reference to a disposed object. Disposal is just something related to application logic.
Destructors can also be cancelled or called more than once by garbage collector (see GC.ReRegisterForFinalize and GC.SuppressFinalize).
The presence of a destructor in a class slow down a lot the garbage collector, and inside destructor, you can do almost nothing except releasing unmanaged resources.
Disposal instead as I said is an application thing, is just a method, and is not related to garbage collector.

"Disposing" an object has nothing to do with which references are kept around. IDisposable itself is just an interface, nothing more.
When a class implements that interface, a user of the class can call a public void Dispose() method on the object. When the user of the class places an instance of the class in a using block, the Dispose() method will automatically get called. When an Enumerator class implements IDisposable and is used in a foreach loop, it will also have Dispose() called on it.
This has absolutely nothing to do with which references are kept around, or the automatic garbage collection system.
However, IDisposable also has a design "contract" that goes with it. This contract is a pattern that classes that implement IDisposable must follow to have correct program behavior.
The contract is that once you've called Dispose(), you should never call any property or method on the object again, otherwise you should expect an ObjectDisposedException to be thrown. The only thing that is allowed to be called on that object after that point is Dispose() again, or the object finalizer (via garbage collection).
Because of this, people will sometimes set an reference to an IDisposable class to null after they have disposed it, so they don't accidentally call methods on the already-disposed object. If you placed the reference in a using block, you don't have to worry about this; The compiler won't even let you touch the reference again. If you try, you will get an error and your program will fail to compile.
This contract is not built into the language or CLR itself - it must manually be adhered to by the implementer of a class.

Yes, it will be. I might be wrong, but I don't think #John Weldon's explanation is not accurate though. You can only call using on an IDisposable implementing class, and when the using exits, it will call Dispose() on the object.
The part where I don't agree is the 'because the referencing object is within the using block scope and will go out of scope at the end of the using block' part. The objects declared in scope will not always be disposed of when the using exits. If you take this example
JustAClass myInstance = new JustAClass();
using ( MyDisposableClass theUsingInstance = new MyDisposableClass() )
{
AnotherClass innerInstance = new AnotherClass();
myInstance.ItsOtherClass = innerInstance;
myInstance.ItsWhatever = theUsingInstance;
}
At the end of this code, myInstance.ItsOtherClass is not null. innerInstance has been created in the using section and won't be garbage collected since there is still a referenced. However, the object refered by myInstance.ItsWhatever has been disposed of, since it's the using target.