How do I 'delete' and object in C#
Author
I am new to C# coming from c++ and the whole thing is driving me mad, lol
I have an object that is created using ... myObject = new myObjectClass();
However I want to destroy the object at a certain point
but I dont know how to delete it.
In c++ this woudl be ... delete myObject;
Is there a way to do this in C#? Thank you
Quote:Original post by SelethD
I am new to C# coming from c++ and the whole thing is driving me mad, lol
I have an object that is created using ... myObject = new myObjectClass();
However I want to destroy the object at a certain point
but I dont know how to delete it.
using statement.
Author
Ok that really doesnt make any sense to me for some reason, i think the examples are just a bit confusing.
I dont like the 'using' way, just seems so 'hack'-ish
And the other way... I only gather that by assigning the 'null' to an object allows it to be destroyed? Is that correct?
so I would just use.... myObject=null;
???
I dont like the 'using' way, just seems so 'hack'-ish
And the other way... I only gather that by assigning the 'null' to an object allows it to be destroyed? Is that correct?
so I would just use.... myObject=null;
???
IIRC there are ways to manually tinker with the garbage collector to make it run when you want, but it's generally not recommended - the results can be unpredictable in terms of performance. The 'using' thing is just an automatic way of calling dispose on a disposable object. If a disposable object has been disposed of then it has been marked for garbage collection, but that doesn't necessarily immediately take place.
It's not a hack though because you might have some resource like an exclusive-access file that an object uses that you want to release when it's no longer needed. Calling dispose on the owning object, or having a 'using' block manage it, can release the file early even though the object hasn't strictly been destroyed yet. You can effectively scope resource ownership despite not controlling garbage collection.
It's not a hack though because you might have some resource like an exclusive-access file that an object uses that you want to release when it's no longer needed. Calling dispose on the owning object, or having a 'using' block manage it, can release the file early even though the object hasn't strictly been destroyed yet. You can effectively scope resource ownership despite not controlling garbage collection.
Yes, setting the last reference to an object to null will mark it for deletion, BUT it will not get deleted right that instance. It's up to the GC to decide when the object is actually deleted.
As a result you can't rely on the destructor for things like closing files and streams, but must make close methods and call them yourself.
As a result you can't rely on the destructor for things like closing files and streams, but must make close methods and call them yourself.
Oh, and assigning null to a reference to something doesn't necessarily mark it for destruction because some other object may have a reference to it too. Only an object that isn't referenced by anything else will be destroyed. Similar to reference-counted smart pointers in C++ if that helps - the deletion occurs when no references exist.
Author
Ok, thanks for all the input. I think until I learn more about it, and feel more comfortable with that aspect of C#, I will just change my coding style to avoid the whole situation.
I appreciate everyone taking time to respond, thank you.
I appreciate everyone taking time to respond, thank you.
Quote:Original post by SelethDYou've got it in one, the trick is to write code that doesn't rely on deterministic destruction. It's quite easy to do, the only downside is you must always manually release any resources you acquire (remembering to close files is the common example) because, unlike C++, you can't predict when the destructor will be executed to close it for you.
I will just change my coding style to avoid the whole situation.
It's possible to tamper with the garbage collector yourself to force it's hand, but that's more for optimisation purposes than anything.
Quote:Original post by dmatterOptmization is a tricky thing when it comes to the garbage collector. Very tricky. There are a few things you need to take into consideration to assure correctness when dealing with managed/unmanaged code interop with respect to garbage collection, but that most certainly is not a performance thing. Optimization though?.... very thin ice you be skating on.
It's possible to tamper with the garbage collector yourself to force it's hand, but that's more for optimisation purposes than anything.
The garbage collector is very good though, and not something you should tamper with unless you know really well what you are doing. It is also not going to be getting you free cycles by calling anything similar to C++'s 'delete' on objects in C# that do not explicitly require you to do so [mostly for the purpose of freeing resources that exist in an un-managed library. See the IDisposable interface, which marks things that fall into that catagory]. You most certainly will not be gaining anything by calling 'collect'.
It really is best not to tamper with something that has already been so carefully tuned. Anyway, the only time you need to call it at all is when it isn't obvious exactly when an object leaves scope [the compiler will flag these bits of data for deletion on its own, because it can figure out when you won't use them anymore]. Sure, the compiler can't figure it ALL out [and provably so], but it can tag the overwhelming majority of the data for deletion when it falls out of scope, and do so immediately [rather than waiting for an exhaustive collection cycle]. You, on the other hand, do not have access to these semantics, and for good reason.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
