Idea: GC and IDisposable

> And how can you decide today how you might optimize a class in 3 years
> time when Microsoft release some new (unmanaged) technology that you could
> use? In the extreme case, you'd have to implement IDisposable on
> practically every class, or just get lucky.

Or you subclass. That's what OOP is about. Adding/changing an interface is
the same in my book as changing the name of every method in the class aloing
with the class itself. It's a major breaking change.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com

Chris,
>> Does the Bitmap constructor create 'managed resources'? [hint: trick
>> question] OK, I'll tell you the answer, on the CF, new Bitmap (...) can,
>> only in some circumstances, create a memory leak if the app does not
>> Dispose() it.
>
> And this is the only case you have for your proposed "fix" and which I
> think is a bug in the Bitmap implemenation. Fixing the Bitmap is a far
> better solution than changing the GC.

You might have missed my post from 9/25 in which I said: "Note: I'm just
using a hypothetical Bitmap class as an example here - let's not go off on a
tangent speaking about the actual Bitmap class." Also, if you look through
my posts, I continually agree that fixing the app is without doubt the
correct thing to do. Other than the usage of (the actual) Bitmap class,
there are no apps anywhere in the C# world that do not call Dispose when
they should?

Anyway, we've beaten this dead horse. Thanks for the input. I enjoyed the
thread, educational as always.

Hilton

"Hilton" <nospam@nospam.com> wrote in message
news:lwvKi.9069$JD.2860@newssvr21.news.prodigy.net ...
>
> Please recall, I'm not saying that my proposal is perfect and that we
> should change our code to use if (it requires no code change in the apps).
> All I'm saying is that if the GC add the "if" as stated above, it would
> act as some level of safety net and catch undisposed objects.

I are just inventing an automatic finalizer for finalizers.
Have you considered the runtime cost?

>
> I think we're kidding ourselves to think that you, me, and all the other
> .NET engineers in the world will always write code to do the right thing.

Nope.

> I really like "using ()" and use it all the time, but there are some
> objects whose lives cannot be bottled up in a few lines.

That is a truism for most code written.

> One little bug and whammo, a LOT of memory potentially gets leaked.

You should try coding in Delphi and C++.

> I cannot even count the times people have posted here about being out of
> memory only to find that they didn't know to Dispose a Bitmap object. The
> purist in you will jump up and down and say "well they should have, they
> screwed up, and they didn't call Dispose() - their fault.".

No, not purists. Realists. And really, - It's their fault!

> Now if only we all lived in a perfect world where one perfect engineer was
> solely responsible for one perfect project...

What would be a wonderful world.

> However, multiple engineers work on multiple projects and one missing
> Dispose() can cost a company millions.

A bad business descision can also cost a company millions.

> Then when we get to finding the problem, we're back to finding the
> problem-causing 'malloc-free' we're all so fond of. :|

That is why we use test-driven application development.
Also, remember it was Apollo 11 that landed on the moon, not Apollo 1.

> Why not add a safety net to make a C# application more robust, less leaky,
> stay up longer, etc? Is it a band aid? Absolutely.

Because for me it is the analogy of adding active armor to a car,
and encourage people to drive recklessly, as;
- Hey, if you crash into something, you just bounce off!

- Michael Starberg