tags:

views:

22

answers:

1

Let's say I'm implementing some wrapper class Foo in C++/CLI. Naturally if I'll create a dtor (Foo::~Foo), it'll become an IDisposable implementation.

IDisposable is typically used to allow immediate release of some "scarce" resource: GDI resources, file handles etc. However, if my IDisposable simply frees memory (e.g. it simply performs free or delete), shouldn't it be done in a regular finalizer (Foo::!Foo), whenever that happens?

I mean, we're okay with the idea that .NET frees memory whenever it likes to, so why give granular control over something that's essentially just freeing memory?

+1  A: 

Personally, I think that releasing memory as early as possible (i.e. as soon as you don't need it) is a good principle. Sure, the GC will kick in and free it, eventually. But the GC uses a single thread to call all finalizers, which can have a bad impact on performance, if there are a lot of finalizers to call.

And you may not feel much difference on a desktop app with a single client, but imagine a server app with hundreds or thousands of clients.

Timores
But you don't expect the same control over deallocation with managed.NET objects, so why with unmanaged objects?For a .NET program, managed objects might be the majority of its allocations, and you don't free those "as soon as you don't need them".
Ilya