Reply to: Garbage Collection rant

[VectraMan]

I can remember moving from C++ to java 10 years ago and being told by my colleagues that garbage collection was flawed and that java would never take off.

Java has never taken off, at least not to the extent that was suggested by all the hype at the time. It's only got anywhere because universites decided it was easier to teach than C++.

We are not paid to write perfect code but maintain bad code handed down to us by the previous freelancer. It your duty fellow contractors to write crap code.

As someone who often has to work on legacy MFC code, I can tell you how true that is.

[AtW]

Use "using" keyword for objects that have Dispose() methods - this would make that method get called once "using" block is done.

I've learnt the hard way that any class I created that uses memory in a non-obvious way (native types) or in large quantity or keeps objects in objects needs to implement IDisposable interface.

Dispose can and gets called automatically without using but you don't get guarantee and you should not count on one - if you deal with stuff like file handles you should always use try/finally block to close file in case of exception happening.

Garbage collection in .NET is pretty good, however one should avoid allocating big chunks of memory and instead try to reuse them. If you use local objects it works okay, but having some complex stuff like file handle object stuffed into global Hashtable/ArrayList can lead to issues.

I've programmed C/C++ in the past and have to say despite garbage collection in .NET not being perfect it still improves productivity big time, if coded well overheads are low too.

[minestrone]

I can remember moving from C++ to java 10 years ago and being told by my colleagues that garbage collection was flawed and that java would never take off.

IN the past one entry point from a method/function was a necessity but really it's just about readability now.

All true contractors must hide at least one return in every function 10 levels of scope in. We are not paid to write perfect code but maintain bad code handed down to us by the previous freelancer. It your duty fellow contractors to write crap code.

[voodooflux]

Okay I admit I was wrong, but to be fair it appears to be a well hidden feature of the language and almost everything I've read says "finalization is non-deterministic" and doesn't give the solution.

Indeed - just reading the MSDN documentation on the dispose pattern and it doesn't seem to mention the using keyword.

[VectraMan]

It's been there since day one - not sure why I didn't mention it earlier, it goes hand in hand with the dispose pattern.

Okay I admit I was wrong, but to be fair it appears to be a well hidden feature of the language and almost everything I've read says "finalization is non-deterministic" and doesn't give the solution.

[Turion]

I was expecting this thread would be about wheelie bins or fortnightly collections or some other interesting rubbish. Only to find that it's about programming

[voodooflux]

Aha! Well that's exactly what I was after, and also kind of proves that I'm right. Was it even in the original version? It seems like a bit of an after thought, and obviously abusing an existing keyword is not exactly a clean solution (although after seeing C++/CLI, nothing scares me anymore).

It's been there since day one - not sure why I didn't mention it earlier, it goes hand in hand with the dispose pattern.

[DimPrawn]

Aha! Well that's exactly what I was after, and also kind of proves that I'm right. Was it even in the original version? It seems like a bit of an after thought, and obviously abusing an existing keyword is not exactly a clean solution (although after seeing C++/CLI, nothing scares me anymore).



Exactly my point. It's not hanging onto an external resource if the lifetime of the object is very short. But thanks to GC, the lifetime could be until the end of the program.

Not really read this thread in depth so apologies if this has been covered but if you have a managed object that holds an unmanaged resource that you want to be got rid of, it is up to you to implement IDisposible (correctly!) and possibly offer an Open and Close method if the resource can be-reused (example being a database connection).

Then any coder will know that to use any class that implements IDisposible, they simply wrap the lifetime of the object in a using statement.

http://stackoverflow.com/questions/1...alization-in-c

http://www.marcclifton.com/tabid/79/Default.aspx

Simple and it works. What's the problem?

[VectraMan]

Not sure how this works in C# but in Java none of the points you outline are a problem at all, providing you follow some sensible coding practices.

None are a problem in assembler either, but that's not really the point.

[jkoder]

Not sure how this works in C# but in Java none of the points you outline are a problem at all, providing you follow some sensible coding practices.

As for any general argument about garbage collection versus manual allocation/deallocation, that's a no brainer.

[VectraMan]

In addition to the try/finally logic, you can also use the Using reserved word on any of your objects that implement IDisposible. They will automatically be disposed off when the code exits the using block either through the normal route or when an error is thrown.

Aha! Well that's exactly what I was after, and also kind of proves that I'm right. Was it even in the original version? It seems like a bit of an after thought, and obviously abusing an existing keyword is not exactly a clean solution (although after seeing C++/CLI, nothing scares me anymore).

An object that is hanging on to an external resource and being referenced in multiple places sounds like a candidate for refactoring to me. Perhaps the object should be a singleton, or if that is not relevant then perhaps it should open and close the resource each time a read or a write is done.

Exactly my point. It's not hanging onto an external resource if the lifetime of the object is very short. But thanks to GC, the lifetime could be until the end of the program.

[FSM with Cheddar]

oops must pay more attention

[voodooflux]

Forgot to mention; An object that is hanging on to an external resource and being referenced in multiple places sounds like a candidate for refactoring to me. Perhaps the object should be a singleton, or if that is not relevant then perhaps it should open and close the resource each time a read or a write is done.

Don't worry, I mentioned it

[FSM with Cheddar]

Forgot to mention; An object that is hanging on to an external resource and being referenced in multiple places sounds like a candidate for refactoring to me. Perhaps the object should be a singleton, or if that is not relevant then perhaps it should open and close the resource each time a read or a write is done.

[FSM with Cheddar]

In addition to the try/finally logic, you can also use the Using reserved word on any of your objects that implement IDisposible. They will automatically be disposed off when the code exits the using block either through the normal route or when an error is thrown.