0

My question is similar to this one: Managing destructors of managed (C#) and unmanaged (C++) objects

But with a twist.

I have, essentially, an object graph, or hierarchy, where class Foo owns some references to multiple instances of class Bar (etc.)

In .NET I have a managed representation of Foo which maintains an IntPtr to the real Foo and uses P/Invoke to call methods on the real Foo (acting as a proxy).

My managed implementation of Foo (the proxy) implements IDisposable.

The proxy Foo contains a readonly property of type List<Bar>.

My managed Bar proxy works the same way (holds unto an IntPtr for the real Bar it represents).

When the real Foo is released, it releases all of it's children (including all Bars).

What is the best approach for dealing with this scenario - as I don't want managed clients of the Foo proxy to get a hold of a reference to a Bar and keep it around longer than they do their reference to the Foo proxy.

Community
  • 1
  • 1
Steve
  • 31,144
  • 19
  • 99
  • 122

2 Answers2

0

Perhaps I'm over-simplifiying this, but your Bar (proxy) class should have a Dispose method that is called by the parent/owner Foo class. And like many classes, once the Bar object has been disposed it should set an internal m_disposed flag to true and throw an ObjectDisposed exception if any of its methods are used afterward. You shouldn't care if the client has a reference to the managed Bar object as long as its internal unmanaged resources have been cleaned up.

tcarvin
  • 10,715
  • 3
  • 31
  • 52
  • The problem I had with this solution is that you imply a parent/child relationship between the `Bar` and `Foo` proxies which doesn't exist. Because I don't know when the underlying `List` items change, I'm creating new managed proxy classes each time the `List` property is called. Keeping references in `Foo` to each `Bar` which was ever created isn't workable (this list could grow to millions of instances). – Steve Sep 08 '11 at 14:27
  • Perhaps I misundestood this "I have, essentially, an object graph, or hierarchy, where class Foo owns some references to multiple instances of class Bar (etc.)" ...doesn't own imply that not imply a parent/child? – tcarvin Sep 08 '11 at 15:10
  • In **unmanaged** land, yes, `Foo` owns several `Bar`s. But in **managed** land, I'm creating new `Bar` proxies every time the List is retrieved. – Steve Sep 08 '11 at 19:40
  • You should probably know - I already solved my problem by implemented a reference counting scheme. I was simply hoping someone may have had some other idea. But, honestly, there is no way I could have gotten around reference counting. I've simplified this question, but in reality, the problem is more complicated - and even ignoring the problem I posted about here I needed the reference counting. – Steve Sep 08 '11 at 19:42
0

I just implemented a simple reference counting scheme.

I was hoping there would be some other way, but, at the end of the day, it was simple, and was really the correct solution.

Steve
  • 31,144
  • 19
  • 99
  • 122