AddThis Social Bookmark Button

Print
Jesse Liberty

Top Ten Traps in C# for C++ Programmers

by Jesse Liberty, author of Programming C#, 2nd Edition
02/11/2002

In an article for the July 2001 MSDN Magazine I talked about what you need to know to move from C++ to C#. In that article, I mentioned that the syntax of C# is very similar to that of C++ and that the difficult part of the transition was not the language itself but getting comfortable with the managed environment of .NET and understanding the extensive .NET Framework.

Iíve begun to compile a list of the syntactical differences that exist between C++ and C#. (See the FAQ from my book, Programming C#, at www.LibertyAssociates.com.) As you might expect, most of the syntactic changes are small and nearly trivial. There are, however, some changes that are potential traps for the unwary C++ programmer, and this article will focus on the ten most dangerous.

Trap #1: Nondeterministic finalization and the C# destructor

The biggest difference in C# for most C++ programmers will be garbage collection. You will no longer have to worry about memory leaks and ensuring that pointers are deleted, but you also give up precise control over when your objects will be destroyed.

If you control an unmanaged resource, however, you will need to explicitly free that resource when you are done with it. Implicit control over unmanaged resources is provided by a destructor, which will be called by the garbage collector when your object is destroyed.

C# Essentials

Related Reading

C# Essentials
By Ben Albahari, Peter Drayton, Brad Merrill

The destructor should only release unmanaged resources that your object holds on to, and it should not reference other objects. If you have only managed references you do not need to (and should not) implement a destructor. You want this only for handling unmanaged resources. Because there is some cost to having a destructor, you ought to implement this only on methods that consume valuable, unmanaged resources.

You never call an objectís destructor directly. The garbage collector will call it for you.

How destructors work

The garbage collector maintains a list of objects that have a destructor. This list is updated every time such an object is created or destroyed.

When an object on this list is first collected, it is placed on a queue with other objects waiting to be destroyed. After the destructor executes, the garbage collector then collects the object and updates the queue, as well as its list of destructible objects.

The C# destructor

C#ís destructor looks, syntactically, much like a C++ destructor, but it behaves quite differently. You declare a C# destructor with a tilde as follows:


	~MyClass(){}

In C#, however, this syntax is simply a shortcut for declaring a Finalize() method that chains up to its base class. Thus, when you write:


	~MyClass()
	{
	   // do work here
	}

the C# compiler translates it to:


	protected override void Finalize()
	{
	   try
	   {
	      // do work here
	   }
	   finally
	   {
	      base.Finalize();
	   }
	}

Trap #2: Finalize versus Dispose

Comment on this articleAre there any C# traps you'd like to add to this list?
Post your comments

It is not legal to call a destructor explicitly. Your destructor will be called by the garbage collector. If you do handle precious unmanaged resources (such as file handles) that you want to close and dispose of as quickly as possible, you ought to implement the IDisposable interface. The IDisposable interface requires its implementers to define one method, named Dispose(), to perform whatever cleanup you consider to be crucial. The availability of Dispose() is a way for your clients to say, "Donít wait for the destructor to be called; do it right now."

If you provide a Dispose() method, you should stop the garbage collector from calling your objectís destructor. To stop the garbage collector, you call the static method, GC.SuppressFinalize(), passing in this reference for your object. Your destructor can then call your Dispose() method. Thus, you might write:


	using System;
	class Testing : IDisposable
	{
	  bool is_disposed = false;
	  protected virtual void Dispose(bool disposing)
	  {
	    if (!is_disposed) // only dispose once!
	    {
	      if (disposing)
	      {
		Console.WriteLine("Not in destructor, OK to reference
	other objects");
	      }
	      // perform cleanup for this object
	      Console.WriteLine("Disposing...");
	    }
	    this.is_disposed = true;
	  }
	  public void Dispose()
	  {
	    Dispose(true);
	    // tell the GC not to finalize
	    GC.SuppressFinalize(this);
	  }
	  ~Testing()
	  {
	    Dispose(false);
	    Console.WriteLine("In destructor.");
	  }
	}

Implementing the Close method

For some objects, youíd rather have your clients call the Close() method. (For example, Close makes more sense than Dispose() for file objects.) You can implement this by creating a private Dispose() method and a public Close() method and having your Close() method invoke Dispose().

The using statement

Because you cannot be certain that your user will call Dispose() reliably, and because finalization is nondeterministic (meaning you canít control when the garbage collector will run), C# provides a using statement, which ensures that Dispose() will be called at the earliest possible time. The idiom is to declare which objects you are using and then to create a scope for these objects with curly braces. When the close brace is reached, the Dispose() method will be called on the object automatically:



using System.Drawing;
class Tester
{
   public static void Main()
   {
      using (Font theFont = new Font("Arial", 10.0f))
      {
           // use theFont
      }    // compiler will call Dispose on theFont
      Font anotherFont = new Font("Courier",12.0f);
      using (anotherFont)
      {
          // use anotherFont
      }   // compiler calls Dispose on anotherFont
   }
}

In the first part of this example, the Font object is created within the using statement. When the using statement ends, Dispose() is called on the Font object.

In the second part of the example, a Font object is created outside of the using statement. When we decide to use that font, we put it inside the using statement and when that statement ends, once again Dispose() is called.

The using statement also protects you against unanticipated exceptions. No matter how control leaves the using statement, Dispose() is called. It is as if there were an implicit try-catch-finally block.

Pages: 1, 2, 3

Next Pagearrow