Suggestion: Show warning when resource is not disposed

[luiscubal]

In SFML.Net, not disposing resources can have horrible effects on both performance AND stability of the program.

What I'm suggesting is this, using the dispose finalizers(see http://msdn.microsoft.com/en-us/library/b1yfkh5e.aspx for examples), add a check that, if a resource is being garbage collected without having been previously disposed, then add a Console.WriteLine warning about it(possibly with a stack trace?)
In my opinion, this would be helpful and assist in the development of more stable SFML.Net code.

[omeg]

Seconded. I'm doing just that in my GUI code, it's really helpful. Similar thing for double disposes (although MSDN says it should technically be legal, it's likely a logic bug).

[Laurent]

.Net is a GC language, explicitely disposing resources is not mandatory. It's only an option for users who need very a strict control on their resources. So I don't see the point of making it mandatory by outputing a warning. A "normal" program should be ok without any call to Dispose().

[luiscubal]

Then what about

Code: [Select]


SFMLConfig.EnableDisposingWarnings = true; //false by default


[Laurent]

But not disposing a resource is not an error, so why should it deserve a warning?

[omeg]

But not disposing a resource is not an error, so why should it deserve a warning?

So why have Dispose in the first place? Like you said, it's not an error, but a warning.
It's like saying "You don't need to bother with deleting objects in C++, OS will release all memory when the program terminates anyway!" GC is not meant to manage resources, but memory.
If your SFML objects contain unmanaged resources like OS handles etc, not disposing them will cause handle leaks. Of course you can rely on finalizers, but every finalization will cause object to be promoted to the next generation of managed heap, which means GC will have more work to do than if you disposed the object.

[Laurent]

So why have Dispose in the first place?

To have the option to explicitely release resources, if one really needs to. But it's just an option.

Like you said, it's not an error, but a warning

A warning means you do something bad. Not releasing resources is not bad in my opinion.

GC is not meant to manage resources, but memory.

The GC manages objects, then it's up to these objects to deallocate any unmanaged resources they hold.

If your SFML objects contain unmanaged resources like OS handles etc, not disposing them will cause handle leaks

All objects will be disposed, whether it is by the user, or by the GC. The only difference is that the GC may do it later.
So where are the memory leaks?

Seriously, what's the problem here? If you need to manually dispose objects because you handle too many of them, do it. If you don't, let the GC do its job. Everything's fine in both cases.

[luiscubal]

The GC is non-deterministic. It does dispose, but possibly not at the right time.
SFML is sensitive about this(for instance, if the user has multiple OpenGL contexts), so a GC triggered at the wrong time can easily crash an application.
Also, in the sample code I provided, the user would be explicitly saying that non-disposed objects were logic errors, so if an user doesn't consider non-disposed resources to be bad, then that user wouldn't receive any warnings about that.

[Laurent]

SFML is sensitive about this(for instance, if the user has multiple OpenGL contexts), so a GC triggered at the wrong time can easily crash an application.

What do you mean? It it happens, it's a bug in SFML that should be fixed.

Also, in the sample code I provided, the user would be explicitly saying that non-disposed objects were logic errors, so if an user doesn't consider non-disposed resources to be bad, then that user wouldn't receive any warnings about that.

Ok but this is not relevant in SFML itself. This user would have to find another way to implement this behaviour if he really wants it.

[luiscubal]

It's possible I'm overstating problems with SFML because I'm currently having severe problems(segfaults) in SFML.NET in a tester's computer(which I have no direct access to) and no way to replicate the results on my own machine.

Since the code seems correct, the only source of errors I could possibly think of would be some problem is memory release(the bugs themselves appear at completely weird locations, such as target.Draw(someRectangle), where both target and someRectangle definitively should be valid instances). If you are saying disposal couldn't ever cause corrupt memory, then I'm back at the speculation board.

[Laurent]

Definitely. If something crashes or behaves abnormally, then we need a bug fix, not a new feature.