Click here to Skip to main content
15,860,972 members
Articles / Programming Languages / C#
Article

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

Rate me:
Please Sign up or sign in to vote.
5.00/5 (25 votes)
5 Jul 2008CPOL3 min read 68.8K   413   30   8
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)


Written By
United States United States
Nish Nishant is a technology enthusiast from Columbus, Ohio. He has over 20 years of software industry experience in various roles including Chief Technology Officer, Senior Solution Architect, Lead Software Architect, Principal Software Engineer, and Engineering/Architecture Team Leader. Nish is a 14-time recipient of the Microsoft Visual C++ MVP Award.

Nish authored C++/CLI in Action for Manning Publications in 2005, and co-authored Extending MFC Applications with the .NET Framework for Addison Wesley in 2003. In addition, he has over 140 published technology articles on CodeProject.com and another 250+ blog articles on his WordPress blog. Nish is experienced in technology leadership, solution architecture, software architecture, cloud development (AWS and Azure), REST services, software engineering best practices, CI/CD, mentoring, and directing all stages of software development.

Nish's Technology Blog : voidnish.wordpress.com

Comments and Discussions

 
QuestionIs this information still accurate? Pin
Member 1140839628-Jan-15 0:07
Member 1140839628-Jan-15 0:07 
I am currently debugging a problem where I tried to do pretty much the same but got a stack overflow.
Looking at the generated code with Reflector it looks like this:
C#
[HandleProcessCorruptedStateExceptions]
protected virtual void Dispose([MarshalAs(UnmanagedType.U1)] bool A_0)
{
    if (A_0)
    {
        try
        {
            this.~FooImpl();
        }
        finally
        {
            base.Dispose();
        }
    }
    else
    {
        try
        {
            this.!FooImpl();
        }
        finally
        {
            base.Finalize();
        }
    }
}



Note that it calls the base class Dispose function WITHOUT a bool parameter. Which will of course in turn call the one WITH bool parameter which is virtual and boom we're going in circles.

Do you happen to know when and why this was changed?
AnswerRe: Is this information still accurate? Pin
Nish Nishant20-Apr-15 15:18
sitebuilderNish Nishant20-Apr-15 15:18 
GeneralMy 5! Pin
RakeshMeena13-Jun-11 22:14
RakeshMeena13-Jun-11 22:14 
Generalto ~ or to !.. Pin
gooja19-Sep-08 3:29
gooja19-Sep-08 3:29 
GeneralRe: to ~ or to !.. Pin
gooja19-Sep-08 4:08
gooja19-Sep-08 4:08 
GeneralHelp me have class stand Pin
medop8224-Aug-08 23:29
medop8224-Aug-08 23:29 
GeneralQuestion Pin
Przemyslaw Celej13-Jul-08 10:36
Przemyslaw Celej13-Jul-08 10:36 
GeneralRe: Question Pin
Nish Nishant13-Jul-08 16:42
sitebuilderNish Nishant13-Jul-08 16:42 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.