What are you currently into?
-
Isn't that simple? You need a 'destructor' as soon as your class holds any additional resources like open file handles or everything that has to be created with 'new' (= memory). In a managed language like C# you can simply make a habit of using Dispose() to 'close' (where possible) and then dispose (also where possible) all objects held in the member variables of your classes. And in 'normal' methods you should always think a second about letting a local object simply go out of scope or properly disposing it. Cleaning up an opened file stream, for example, avoids problems when the file has to be accessed again before the garbage collector has taken care of the last object used to access the file. In C# this is a covenience to properly free those resources long before the garbage collection does so. In C++ this is a must, unless you like memory leaks or inaccessible files.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.It's not quite that simple. What happens, for example, when a Disposable Object holds a reference to another IDisposable that might still be referenced by other Objects? Calling Dispose should Dispose of managed and unmanaged resources, while the GC can only free managed resources (something like that). So to properly clean all your Objects you should wrap unmanaged resources in managed Objects that Implements IDisposable and have those Dispose in the Disposer of the Object that uses it and always call Dispose, which might dispose Objects that are still referenced... *Head explodes* ... ... Just believe me, it's not that simple ;p Just think of this. IEnumerator does not Inherit from IDisposable, IEnumerator<T> does. This basically means that IEnumerators are (probably) NOT properly disposed even though they Implement IDisposable. IEnumerator<T> is ALWAYS disposed even though you won't need it 99 out of 100 times (perhaps even more). In this case IEnumerator and IEnumerator<T> kind of break Liskov's substition principle because a derived Class should be handled differently than a base class. And this might be the case for any derived class Implementing IDisposable... So every Object that uses a Class and makes it go out of scope should always check if the Object is an IDisposable and call Dispose if it is (for example when using Factory Classes, instantiating a possible IDisposable Object, using that and then Disposing it). As my vague explanation proves I am no expert on IDisposable and memory management. But I hope you can understand some troubles concerning IDisposable :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
The rule of thumb is fairly simple: explicitly dispose anything which uses restricted or unmanaged resources. If it's just memory then the garbage collector will grab it when appropriate, but if it's something that might run out or cause a problem before the garbage collector arrives (file handles and graphics resources are the usual ones, though I think graphics objects are cached or reused because I've written lots of things which don't Dispose local pens/brushes and never had an issue). The garbage collector will call Dispose as part of finalisation, so all your IDisposables will, eventually, get disposed – but quite possibly not in a time frame that you are happy with.
See my post below[^] for a reaction. I'm no expert, so I hope what I'm saying is true and at least somewhat clear ;p
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
It's not quite that simple. What happens, for example, when a Disposable Object holds a reference to another IDisposable that might still be referenced by other Objects? Calling Dispose should Dispose of managed and unmanaged resources, while the GC can only free managed resources (something like that). So to properly clean all your Objects you should wrap unmanaged resources in managed Objects that Implements IDisposable and have those Dispose in the Disposer of the Object that uses it and always call Dispose, which might dispose Objects that are still referenced... *Head explodes* ... ... Just believe me, it's not that simple ;p Just think of this. IEnumerator does not Inherit from IDisposable, IEnumerator<T> does. This basically means that IEnumerators are (probably) NOT properly disposed even though they Implement IDisposable. IEnumerator<T> is ALWAYS disposed even though you won't need it 99 out of 100 times (perhaps even more). In this case IEnumerator and IEnumerator<T> kind of break Liskov's substition principle because a derived Class should be handled differently than a base class. And this might be the case for any derived class Implementing IDisposable... So every Object that uses a Class and makes it go out of scope should always check if the Object is an IDisposable and call Dispose if it is (for example when using Factory Classes, instantiating a possible IDisposable Object, using that and then Disposing it). As my vague explanation proves I am no expert on IDisposable and memory management. But I hope you can understand some troubles concerning IDisposable :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}Naerling wrote:
Just believe me, it's not that simple ;-P
I know that. That's why it is a good practice to give some object control over the lifecycle of other objects, from instantiation to destruction. It's the idea behind more or less abstract class factories. When disposing, a class should simply clean up whatever is under its own control and leave all objects under another control of another class alone. Such problems only arise when objects are instantiated on the fly and passed around without some other object feeling responsible for it. As to your other example: Is IEnumerator really derived from IEnumerator? Or are they just two different interfaces which share some similarities? Anyway, don't confuse Dispose() with Finalize(). Every object has a finalizer, Dispose() only adds the capability to do the finalization at a time of your choice long before the garbage collector does finalize an object before removing it. Not disposing an object does little harm as long as you can afford to wait for some resources until the garbage collector has freed them.
-
Marc Clifton wrote:
a deeper understanding of what it is we're doing
I think that's key to becoming a good programmer! I work at a company that went from a custom DB tool someone wrote once to a quick flirt with "typed datasets" to Entity Framework. As a result none of my colleagues knows how to use DbConnection, DbCommand and DbAdapter Objects... It's the first thing I started to explore when we switched to typed data sets. I also found out they were not as "typed" as we believed. I didn't want to work with those typed data sets, so I started using DbCommand Objects out of protest (yes, I am that kind of guy. It was only a prototype project anyway). It was not in vain since we now use Entity Framework 4.0. Although it took an MVP to convince my employers what I had been saying for weeks... :~ Knowing what's going on keeps you from making wrong decisions or choosing tools you don't need.
Marc Clifton wrote:
I'm mainly into looking at the idea of making relationships more first class citizens
Interesting idea. Can we expect an article on that anytime soon? :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
Naerling wrote:
Just believe me, it's not that simple ;-P
I know that. That's why it is a good practice to give some object control over the lifecycle of other objects, from instantiation to destruction. It's the idea behind more or less abstract class factories. When disposing, a class should simply clean up whatever is under its own control and leave all objects under another control of another class alone. Such problems only arise when objects are instantiated on the fly and passed around without some other object feeling responsible for it. As to your other example: Is IEnumerator really derived from IEnumerator? Or are they just two different interfaces which share some similarities? Anyway, don't confuse Dispose() with Finalize(). Every object has a finalizer, Dispose() only adds the capability to do the finalization at a time of your choice long before the garbage collector does finalize an object before removing it. Not disposing an object does little harm as long as you can afford to wait for some resources until the garbage collector has freed them.
CDP1802 wrote:
Is IEnumerator<T> really derived from IEnumerator?
Yes, I wrote an article[^] about it (didn't go into the IDisposable 'detail' though). Check the picture in the "Enumerator" sub-section. :) As of the rest of your post, neither Finalizer nor Dispose clean up unmanaged resources unless you call Dispose from code. "The .NET garbage collector manages the memory of managed objects (native .NET objects) but it does not manage, nor is it directly able to clean up unmanaged resources."[^], which is also in the article I linked a few posts up. The article I just linked gives the example of a DB connection. Should an Object keep an (unmanaged) DB connection open until Dispose is called this will not be closed when you simply wait for the GC. That's why managed wrappers around unmanaged code are absolutely necessary! You can see however, that if IEnumerator would open up a connection and close it in a Dispose method Dispose is probably not called when iterated over the Enumerator (unless Microsoft checks for any Enumerator if it is also IDisposable). Where would you call Dispose now? Now keeping a connection open like that may not be the best practice, but this sort of thing is exactly why IEnumerator<T> DOES Implement IDisposable. So did I understand some stuff wrong and is it not, in some cases, absolutely necessary to call Dispose explicitly (where this is not always easily possible)?
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
Naerling wrote:
Can we expect an article
Indeed!
Naerling wrote:
anytime soon?
Aye, there's the rub! Marc
Good news! And I'm not in a hurry. Lots of other stuff to keep me busy :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
Isn't that simple? You need a 'destructor' as soon as your class holds any additional resources like open file handles or everything that has to be created with 'new' (= memory). In a managed language like C# you can simply make a habit of using Dispose() to 'close' (where possible) and then dispose (also where possible) all objects held in the member variables of your classes. And in 'normal' methods you should always think a second about letting a local object simply go out of scope or properly disposing it. Cleaning up an opened file stream, for example, avoids problems when the file has to be accessed again before the garbage collector has taken care of the last object used to access the file. In C# this is a covenience to properly free those resources long before the garbage collection does so. In C++ this is a must, unless you like memory leaks or inaccessible files.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.CDP1802 wrote:
Isn't that simple? You need a 'destructor' as soon as your class holds any additional resources like open file handles or everything that has to be created with 'new' (= memory). In a managed language like C# you can simply make a habit of using Dispose() to 'close' (where possible) and then dispose (also where possible) all objects held in the member variables of your classes. And in 'normal' methods you should always think a second about letting a local object simply go out of scope or properly disposing it. Cleaning up an opened file stream, for example, avoids problems when the file has to be accessed again before the garbage collector has taken care of the last object used to access the file.
Doesn't sound simple to me and I'm pretty sure there's more to the story but I might be wrong as its a long time since I've had to look into the subject.
-
The last year I have been programming WinForms most of the time. I recently started doing some WCF too. I tried doing some WPF (but got distracted by F#). So I was doing F#, but got distracted by some cool WinForms designer stuff I didn't know yet... And back at WinForms I was. And that's basically how I've been going around in circles. There is a lot to learn when programming WinForms, but it is a somewhat outdated technology. I feel I should be doing WPF, but F# looks really nice too. I also wanted to do some C++ (which I did for about two evenings) because I want to know a bit more about why some stuff is how it is (and a lower level language seems like a good way to learn). Knowing more about pointers and memory management has my special interest. But that won't help me in WPF or WCF or F# or... And now we're going to use Microsoft Enterprise Library at work too, so I am supposed to do some of that too! There is just so much to learn (old and new) and there is more coming still! I was just curious, are people here currently learning some new language, technique, framework etc.? And why? For all the people who are going to shout "No programming questions in the lounge!", this is NOT a programming question. It's a question about programming :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}Android all the way, baby! After almost 20 years of Turbo Pascal, C#, then a little Java, I'm "all about" Android now, and expect to be for years to come.
-
The last year I have been programming WinForms most of the time. I recently started doing some WCF too. I tried doing some WPF (but got distracted by F#). So I was doing F#, but got distracted by some cool WinForms designer stuff I didn't know yet... And back at WinForms I was. And that's basically how I've been going around in circles. There is a lot to learn when programming WinForms, but it is a somewhat outdated technology. I feel I should be doing WPF, but F# looks really nice too. I also wanted to do some C++ (which I did for about two evenings) because I want to know a bit more about why some stuff is how it is (and a lower level language seems like a good way to learn). Knowing more about pointers and memory management has my special interest. But that won't help me in WPF or WCF or F# or... And now we're going to use Microsoft Enterprise Library at work too, so I am supposed to do some of that too! There is just so much to learn (old and new) and there is more coming still! I was just curious, are people here currently learning some new language, technique, framework etc.? And why? For all the people who are going to shout "No programming questions in the lounge!", this is NOT a programming question. It's a question about programming :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}Currently I'm sticking with C#, brought onboard from C++ in order to do do XNA with a detour for WinForms. And, of course, C preceeded the C++. I'd love to be able to do it all but there's no time to handle it all. And not being in a programming shop I have no cohorts off of whom I can feed. So I stay with the do-it-all for me.
I'm not a programmer but I play one at the office
-
The last year I have been programming WinForms most of the time. I recently started doing some WCF too. I tried doing some WPF (but got distracted by F#). So I was doing F#, but got distracted by some cool WinForms designer stuff I didn't know yet... And back at WinForms I was. And that's basically how I've been going around in circles. There is a lot to learn when programming WinForms, but it is a somewhat outdated technology. I feel I should be doing WPF, but F# looks really nice too. I also wanted to do some C++ (which I did for about two evenings) because I want to know a bit more about why some stuff is how it is (and a lower level language seems like a good way to learn). Knowing more about pointers and memory management has my special interest. But that won't help me in WPF or WCF or F# or... And now we're going to use Microsoft Enterprise Library at work too, so I am supposed to do some of that too! There is just so much to learn (old and new) and there is more coming still! I was just curious, are people here currently learning some new language, technique, framework etc.? And why? For all the people who are going to shout "No programming questions in the lounge!", this is NOT a programming question. It's a question about programming :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}I am currently going away from the Microsoft stack. Starting to learn PHP, Ruby, Linux and MySql. I have done just about as much as I can with Microsoft Stack so I am moving in a little different area. Things I have worked on with Microsoft tech is Vb.net, C#, classic asp, asp.net Web Forms, asp.net MVC, C++ MFC, WPF, WinForms, WCF, SharePoint, SqlServer, WF, and Exchange. Plus it is making me think of things in a different light which helps all around. Another reason I am going away from the Microsoft stack is because I do it all day long at my job and so it is more fun to dive into something completely new. I really like PHP right now but I am only using it on small projects for fun. Ruby I haven't done much with yet so the jury is still out on that one.
-
The last year I have been programming WinForms most of the time. I recently started doing some WCF too. I tried doing some WPF (but got distracted by F#). So I was doing F#, but got distracted by some cool WinForms designer stuff I didn't know yet... And back at WinForms I was. And that's basically how I've been going around in circles. There is a lot to learn when programming WinForms, but it is a somewhat outdated technology. I feel I should be doing WPF, but F# looks really nice too. I also wanted to do some C++ (which I did for about two evenings) because I want to know a bit more about why some stuff is how it is (and a lower level language seems like a good way to learn). Knowing more about pointers and memory management has my special interest. But that won't help me in WPF or WCF or F# or... And now we're going to use Microsoft Enterprise Library at work too, so I am supposed to do some of that too! There is just so much to learn (old and new) and there is more coming still! I was just curious, are people here currently learning some new language, technique, framework etc.? And why? For all the people who are going to shout "No programming questions in the lounge!", this is NOT a programming question. It's a question about programming :)
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}My day job has me doing Silverlight/ASP.net for a year now with little change in sight. Playing around... I’m actually moving away from the oss stacks. Android OS has a nice design, but setting up the tools just sucks. I’m currently a month into Unity3d and enjoying it. I’ll probably dive into Electrotank’s es5 server next.
