Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / Languages / C#

C++/CLI HowTo : Deriving from a C# disposable class

5.00/5 (25 votes)
5 Jul 2008CPOL3 min read 1   414  
This article walks through the implementation of a C++/CLI class from a disposable C# base.

Introduction

Last week at work, I had to work on a C++/CLI class that derived from a class written in C# which implemented IDisposable. I got it wrong at first (yeah, same guy who wrote a book on the subject a couple of years ago), and my boss and I spent some time going through the generated code in Reflector before fixing it up. I came home that night and quickly put together a simple project so I could see the whole picture from a simple perspective. I thought it would benefit others to put together an article reflecting (no pun intended) the issue.

The C# base class

Here's a simple C# class that implements IDisposable. It's assumed that the class handles both managed and native resources.

C#
namespace DisposeDemo
{
    [SuppressMessage("Microsoft.Naming", 
        "CA1709:IdentifiersShouldBeCasedCorrectly", 
        MessageId = "Cs", 
        Justification = "Personal preference")]
    public class CsDisposableBase : IDisposable
    {
        #region IDisposable Members

        public void Dispose()
        {
            Dispose(true);
            GC.SuppressFinalize(this);
        }

        ~CsDisposableBase()
        {
            Dispose(false);
        }

        /// <summary>
        /// Derived classes need to override this appropriately
        /// </summary>
        /// <param name="disposing">Indicates whether this is a dispose call
        /// or a call invoked from the finalzier</param>
        protected virtual void Dispose(bool disposing)
        {
            if (disposing)
            {
                DisposeManagedResources();
            }

            FreeNativeResources();
        }

        #endregion

        private void DisposeManagedResources()
        {
            this.WriteLine("Disposing managed resources in base class");
        }

        private void FreeNativeResources()
        {
            this.WriteLine("Freeing native resources in base class");
        }

        public CsDisposableBase(String name)
        {
            this.Name = name;
        }

        public String Name { get; private set; }

        protected void WriteLine(String text)
        {
            Console.WriteLine("{0} : {1}", this.Name, text);
        }
    }
}

For any C# developer inheriting from this class, it's a no-brainer to override and implement void Dispose(bool) as the class requirements dictate. But things are not so obvious from C++/CLI. C++/CLI does not permit any method named "Dispose" in your class. While you've all probably implemented IDisposable classes in C++/CLI before, you may not have yet derived from a C# IDisposable base before. Anyway, the trick is to avoid over-thinking and complicating the issue - all you need to do is to handle it just as you'd do normally. Put the managed-disposal in the destructor and the native-disposal in the finalizer.

The C++/CLI derived class

Here's the derived class implementation in C++/CLI:

MC++
namespace CppDisposable
{
  public ref class DisposableDerived : CsDisposableBase
  {
  private:
    void DisposeManagedResourcesDerived()
    {
      WriteLine("Disposing managed resources in derived class");
    }

    void FreeNativeResourcesDerived()
    {
      WriteLine("Freeing native resources in derived class");
    }

  public:
    ~DisposableDerived()
    {
      DisposeManagedResourcesDerived();
      this->!DisposableDerived();
    }

    !DisposableDerived()
    {
      FreeNativeResourcesDerived();
    }

    DisposableDerived(String^ name) : CsDisposableBase(name)
    {
    }

  };
}

At first glance, the code seems wrong. How do we ensure that the base class disposal code (and the finalizer) are called as and when needed? Let's write some test code to see what happens.

MC++
int main(array<System::String ^> ^args)
{
  CppDisposable::DisposableDerived object1(
    "Object that gets disposed");

  CppDisposable::DisposableDerived^ object2 =
    gcnew CppDisposable::DisposableDerived("Object that gets GCd");
  return 0;
}

Running that gives the following output :-

Image 1

Wow. Everything worked fine. How did that happen? The answer lies in VC++ compiler magic. A look at the generated code using Reflector shows us that the compiler has generated the code that we may otherwise have had to write ourselves.

What Reflector shows

Here's the generated code (as viewed in Reflector):

C#
protected override void Dispose([MarshalAs(UnmanagedType.U1)] bool flag1)
{
    if (flag1)
    {
        try
        {
            this.~DisposableDerived();
        }
        finally
        {
            base.Dispose(true);
        }
    }
    else
    {
        try
        {
            this.!DisposableDerived();
        }
        finally
        {
            base.Dispose(false);
        }
    }
}

So, during a Dispose call, here's what will happen:

  1. The C# base class Dispose will call Dispose(true) and suppress GC.
  2. The C++/CLI implementation will call ~DisposableDerived (which frees the managed resources in the derived class and then calls !DisposableDerived which frees the native resources in the derived class).
  3. Now, base.Dispose(true) is called (in the finally-block) which frees the managed and native resources in the base class.

And this is what happens during a finalization:

  1. The C# base class finalizer calls Dispose(false).
  2. The C++/CLI implementation calls !DisposableDerived (which frees the native resources in the derived class).
  3. And base.Dispose(false) is called (in the finally-block) which frees the native resources in the base class.

Essentially, this code is exactly what we'd have needed to write - the compiler generates it for us.

Conclusion

I know this is a very simple article, but sometimes it's the simple things that we stumble over. I wish I had covered this topic in my book (where I talk about deterministic destruction). As always, please feel free to submit feedback (critical or otherwise).

History

  • July 5, 2008 - Article published.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)