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

[Armando]

I wasn't interested in the C# vs other languages aspect, but more the fact that...

the JIT compiler can do "lookahead optimization", and may mark any object for collection after what it considers it's "last use", ignoring scope

Weird.
Maybe some of you will find that interesting too...

[worstje]

I know of it. I hate that. Forcing me to use a GC language is one thing - not giving me sufficient control about when stuff gets released is another.

There must be some sort of technical reason, but the entire Dispose() thing is a disaster that feels as if they came up with it after the fact: 'oh, crap, some resources actually can't be garbage collected'. I am actually too tired to remember what exactly got me angry about the entire GC&resources thing in the first place; I just remember it gave me tons of shit when devving at some point. It's not exactly the same thing you talk about, obviously.

The entire GC affair just shows to me how people forget or don't learn the importance of symmetry and responsibilities when programming. You allocate something, you need to release it. That simple rule has helped me personally so much about learning where the responsibilities lie in code, given me so much insight that pure OO did not show me, and most of all it taught me how to keep programs working. So many of those new applications (usually .NET ones) are just so pathetic: huge memory hogs, crawling to a slow the longer you run it. People simply don't care about their garbage.

[Renegade]

GC is a two-edged sword.

99.9% of the time it's amazing.

Then, there's that 0.1% where it's black magic, requiring dark incantations, sacrifices, and mortgaging parts of your soul.

There are rare instances where you need to force GC. I've seen a couple, and don't like them at all. Still, it's what it is, and the small amount of pain is worth avoiding other pains that it solves.

Lambda expressions and anonymous delegates are 2 examples where "scope" kind of alters meaning.

You can have a method finish, but your lambda expression code can still be running. They're nice, terse ways to express functionality, but they come from functional programming and look somewhat odd in the context of OO programming, and are counter-intuitive when you look at them the first time.

I'm sure there are other reasons for object lifetime not being entirely determined by scope, but that's one look at "scope".

[phitsc]

There must be some sort of technical reason, but the entire Dispose() thing is a disaster that feels as if they came up with it after the fact: 'oh, crap, some resources actually can't be garbage collected'. I am actually too tired to remember what exactly got me angry about the entire GC&resources thing in the first place; I just remember it gave me tons of shit when devving at some point. It's not exactly the same thing you talk about, obviously.

-worstje (May 05, 2011, 11:50 AM)

I completely agree! The fact that you need to bother with something like the Dispose pattern in a modern programming language is just embarrassing. And error prone as well.

[worstje]

Lambda expressions and anonymous delegates are 2 examples where "scope" kind of alters meaning.

You can have a method finish, but your lambda expression code can still be running. They're nice, terse ways to express functionality, but they come from functional programming and look somewhat odd in the context of OO programming, and are counter-intuitive when you look at them the first time.

I'm sure there are other reasons for object lifetime not being entirely determined by scope, but that's one look at "scope".

-Renegade (May 05, 2011, 03:57 PM)

I fully agree, those things do change matters. My particular rant is towards the following C# pattern:

[Select]

public bool SomethingSomething(string filename)
{
    SomeClass sc = new SomeClass();
    // or ...
    SomeClass sc2 = obtainClassForFile(filename);

    // Do stuff
    sc.DoStuffWith(sc2);

    // The end.
}

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.

But it messes big time with our ability, as programmers, to recognise bad situations. I am a big fan of Joel Spolsky's Making Code Look Wrong article, even though I fail to use those techniques properly half the time as I code too many little things where it does not matter rather than big systems with different sorts of data where such consistency does shine. It explains very well how for code to be maintainable and understandable after you have written it, recognisable patterns are ideal.

In the case of local variables I gave above, you cannot ever be certain you used it properly, unless you decide to throw a using() statement around every temporary object you create (and that will lead to code that is overly verbose which has its own issues). The simpler code I wrote above cannot ever tell you 'I did this right', but it can only say 'it looks fine to me'. No! You want the code to say 'Damn, this looks totally wrong!' and get down to fixing it. You do not want code that says 'It might be wrong, but it might not be.', since you either end up ignoring the pattern, or you fruitlessly debug tons of correct code - neither of which is healthy to your sanity in the short term or the long term.

Sorry, I rant again. But I'm a bit more awake right now than I was last time I posted.

[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)

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)

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

[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!

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.

[Renegade]

Samsung bada uses complete encapsulation, which is actually very nice in a lot of ways. You see a lot of that in Java as well.

Along with encapsulation, methods return "result" types, and what you need to destroy is pretty explicit. Methods are marked "MethodNameN" where explicit destruction is required. I like that. It kind of goes along with that article of Joel's above.

[worstje]

Oh, that sounds good. I approve.

[mouser]

I also am in the camp that is deeply distrustful of garbage collection in all but specialized cases.  I understand that it can be incredibly useful and helpful in many cases, but i find it unacceptable when a language doesn't have a way for me to *easily* take responsibility for explicitly allocated and freeing object memory.

Memory may be relatively abundant but it's not infinite.  For those of us who occasionally work on projects that need to use as much memory as they possibly can get access to, not being able to control or predict memory use is unacceptable.

This reminds me of one of my pet peeves -- the C++ standard library (and others like Boost) are heavily focused on creating very "optimal" algorithms for sorting, representing trees, graphs, dictionaries, etc.  And you can find elaborate discussions about runtime performance in best/avg/worst case scenarios for these algorithms, etc.  But almost no one ever spends any time looking at or reporting the memory use efficiency, and none of the classes or algorithms has any way to report to you how much memory they are actually using.  Not cool.

[CWuestefeld]

Back in the days when I used C++, I had a pattern that kept memory cleanup pretty clear. If you own an object, you're responsible for seeing that it's cleaned up. And if you've got a pointer to the object (as opposed to a reference), then you own it.

But I've been using C# for quite awhile, and have no problem with the GC in .Net. the using(){} pattern is easy to use, and does just fine. I've got a performance-critical app I finished a few months ago that holds a whole database of a hundred million objects in a Dictionary, using it to build other collections of a few hundred thousand objects at a time. This thrashes huge amounts of RAM, but is performant enough that the CPU and RAM usage is barely noticeable, dwarfed by the cost of writing out the results.

I think that one way people get themselves into trouble is that they fail to differentiate properly between class and struct. There's the obvious (but still poorly-understood, oddly) issue of boxing, but they have different performance characteristics in other ways as well. Plus the use of sealed, readonly, etc., can give the compiler/JITter a lot of help.

[phitsc]

But I've been using C# for quite awhile, and have no problem with the GC in .Net. the using(){} pattern is easy to use, and does just fine. I've got a performance-critical app I finished a few months ago that holds a whole database of a hundred million objects in a Dictionary, using it to build other collections of a few hundred thousand objects at a time. This thrashes huge amounts of RAM, but is performant enough that the CPU and RAM usage is barely noticeable, dwarfed by the cost of writing out the results.

-CWuestefeld (May 06, 2011, 11:56 AM)

Yeah, experience does the trick! It's just that I always hear people saying how C# was better suited for less experienced programmers (contrary to C++), because it has garbage collection   (I'm exaggerating obviously)

If you forget to call delete in C++ (or don't know what a smart pointer is), you get a memory leak. If you forget to use using in C# (or don't know how to properly implement Dispose in a class hierarchy) you might get a resource leak. The point I'm trying to make: you need to know your stuff, no matter what language you're using.

[Renegade]

Memory may be relatively abundant but it's not infinite.  For those of us who occasionally work on projects that need to use as much memory as they possibly can get access to, not being able to control or predict memory use is unacceptable.

-mouser (May 06, 2011, 11:12 AM)

This is the reason why I see .NET as utterly brilliant.

For situations where you really need that precision with memory, you're free to use another language. For UI code, you can use another. For another component that's better suited to functional language, you have F#.

Programming isn't a 1-size fits all thing. No 1 language is THE answer. (Except if you ask a friend of mine, who is probably the most brilliant programmer I know, he'll say C is THE ANSWER. )

It seems to me that using the right language, with the right programmer, and making careful decisions in your architecture, etc., can yield results that balance productivity with performance.

[Shades]

42 is the answer :-)

...as far as I know (and after any HGTG quote you can take that as literally as you like it  )


Sorry, lack of sleep makes me "melig" which is Dutch for: rambling (in a positive way)

[wraith808]

It seems to me that using the right language, with the right programmer, and making careful decisions in your architecture, etc., can yield results that balance productivity with performance.

-Renegade (May 06, 2011, 10:38 PM)

This.  I remember my most used class from college was "Organization of Programming Languages".  It was a senior level course purposed only with showing how much more languages are alike than different.  And the final project was to code a decently complicated project in a month in a language that was randomly assigned from languages that we didn't know.  A lot easier than it sounds; it wasn't my best work architecturally, but that wasn't the point.  His position was that we limit ourselves in what we can do by limiting our language choice.  Realistically, you have to specialize to get ahead.  But if you can bring something to the table other than what you specialize in, you definitely have a leg up on someone who only knows the one language.