Other Software > Developer's Corner

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

(1/4) > >>

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
--- End quote ---
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)
--- End quote ---

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)
--- End quote ---

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


--- ---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. :)

Navigation

[0] Message Index

[#] Next page