Hi all,
I am writing a component that exposes a C++ library as a .NET
component. The approach is somewhat automatic: every library C++ class
has its managed C++ counterpart that keeps a pointer to the unmanaged
class instance.
As usually in such a scenario, the IDisposable/Dispose()/Dispose(bool)
pattern should be used. The problem is that in my approach it is often
impractical, as the library's unmanaged objects are quite small and
many of them are created in various places. For example, such a
statement:
O1 o = o2.Prop1.Prop2;
looks quite nice and it is a lot more convenient than:
using (O3 o3 = o2.Prop1) {
using (O1 o = o3.Prop) {
}
}
The problems stems from the fact that lots of small objects are
created. I have found the following 2 approaches to deal with
unmanaged memeory releasing:
1. Do not do anything (wait for GC to collect managed objects and run
finalizers on them, which call delete on internal pointers). Well, I
have performed some stress tests and it seems to work fine - the
memory as displayed by the Windows Task Manager periodically grows and
decreases to the (approximately) the same value.
2. The problem may appear when the unmanaged heap goes out of space
first. So, to address such a situation, I believe that instead of
calling Dipose() on every small object (wrapper), one could do:
using (UnmanagedMemor yManager mm = MyLib.GetMemeor yManager()) {
// do whatever you want, all new objects (wrappers) created
// by the library in this thread will be automatically added
// to the manager and released in Dispose()
O1 o = o2.Prop1.Prop2;
// we want 'o' to stay usable after the using() block finishes;
// tell the manager to not bother about 'o'
mm.DoNotManage( o);
} // call mm.Dispose() and release all objects managed by the
manager,
// which does not include 'o'
return o;
As one can see, the library could have a thread-relative memory
manager and all library objects that require releasing the memory
could be released in "one shot".
What do you think about it?
Best regards,
Marek
