Other Software > Developer's Corner

C# : Object Lifetime is Not (entirely) Determined by Scope ?

<< < (2/4) > >>

wraith808:
Nobody ever frees sc nor sc2. Should I have used using() on this so Dispose() gets called automatically? Maybe. Or maybe not. This pattern works just fine for temporary 'local' types like arrays and the sort.

Woop de wooping wah wah, the GC helps me out by taking the worry of free()ing things away. But now nobody knows WHEN it happens exactly. And there is the pain of garbage collectors running and slowing down your app as a result unless they are very well optimized. Most of the time, it makes no difference.
-worstje (May 06, 2011, 08:03 AM)
--- End quote ---

I actually like the fact that GC takes care of a lot of that, since freeing the memory has nothing to do with compacting the memory, which GC takes care of also.  And the costs of doing this are not insignificant.  If the item hasn't survived GC once it passes from scope, it's very unlikely that it will be around in any case.  The only real thing that you have to remember if the object is not IDisposable is to manage your references to the object to make sure that there is not any unused reference keeping the object around past gen1.  There are cases where this is more of an issue, but I find them few and far between to compare to the advantages of not having to deal with that.  And if you want more control, there's always unmanaged code...

Renegade:
I must admit, in some utility data processing applications I've written (not released), I've had GC problems as memory wasn't collected fast enough and I ran into out of memory errors. The problem is especially bad with imaging as underneath it used GDI+, which isn't re-entrant, which someone here pointed out... I forget who now though...

But most of the time, I love it.

worstje:
I actually like the fact that GC takes care of a lot of that, since freeing the memory has nothing to do with compacting the memory, which GC takes care of also.  And the costs of doing this are not insignificant.  If the item hasn't survived GC once it passes from scope, it's very unlikely that it will be around in any case.
-wraith808 (May 06, 2011, 08:51 AM)
--- End quote ---

I could live with the implicit free() far better if it was at least deterministic to doing the Dispose() and destructor stuff the moment it passes out of scope. But I do not know when it happens. It could be ages until it goes through its cleanup cycle, and whether or not destructors run can simply make a giant difference on decisions taken later on in the program. But it is not deterministic, so I advocate being explicit, but that works best if it is required or the point is indeed moot.

you know... to me an explicit free() or too is just like capitalizing your ts and spell tjekking and all that stuff, an putting your dots and periods and shit after your sentences it certainly makes it a hole lot moar readable dont you think 8)

phitsc:
What bothers me most is that people always praise how GC gets rid of memory related bugs (in that the programmer is not responsible for freeing memory any more), while never talking about the problems that come with it, like the programmer now having to know if an object allocates resources other than memory, the programmer now having to know about using, dispose, finalizers, GC.SuppressFinalize, how to deal with derived classes, when to use sealed, etc.

While GC might be really cool if you only have to deal with memory, everything gets much more complicated (compare to RAII) when dealing with resources other than memory, especially when something like exception safety comes into the picture.

worstje:
Amen, brother, amen! :Thmbsup:

Exceptions have their own issues. They are nice, but they also have a certain degree of non-determinism attached to them from the coders point-of-view once one starts dealing with 'black boxes', also known as functions-in-other-libraries-you-do-not-have-the-source-for.

I have a lot of reasons to dislike Java, but one thing it does right (in my opinion) is that it requires an explicit listing of exceptions a function can throw, or it will throw a compile error for an error not caught. It requires you to be aware of the state your program can be in at the time an error occurs, assuming you do not subscribe to the stick-your-head-under-the-sand school of programming. Exceptions as they are in C#, C++ and related languages are little more than GOTOs with a bit more structure - but in the end, the flow of execution can still be very abhorrent and unclear, leading to bugs that by their very nature tend to happen in unusual situations and are thus hard to find and reproduce.

Navigation

[0] Message Index

[#] Next page

[*] Previous page