Developer Backgrounds in Memory Management

Your experience with memory management will vary depending upon your development background. In certain situations, you will need to adapt your programming practices to the automatic memory management provided by the common language runtime.

COM Developers

COM developers are accustomed to implementing reference counting as a manual memory management technique. Each time an object is referenced, a counter is incremented. When a reference to an object goes out of scope, the counter is decremented. When an object's reference count reaches zero, the object is terminated and its memory is freed.

The reference counting scheme is the source of many bugs. If the reference counting rules are not followed precisely, objects might be freed prematurely or unreferenced objects might accumulate in memory. Circular references are also a common source of bugs. A circular reference occurs when a child object has a reference to a parent object, and the parent object has a reference to the child object. This scenario prevents either object from being released or destroyed. The only solution is for the parent and child objects to agree on a fixed pattern of usage and destruction, such as where the parent always deletes the child first.

When you develop applications in a language that targets the common language runtime, the runtime's garbage collector eliminates the need for reference counting and, as a result, the bugs that can arise from this manual memory management scheme.

C++ Developers

C++ developers are accustomed to the tasks related to manual memory management. In C++, when you allocate memory for an object using the new operator, you must release the object's memory using the delete operator. This can lead to errors such as forgetting to release an object and causing a memory leak, or attempting to access memory for an object that has already been released.

When you develop applications using the Managed Extensions for C++, or another language that targets the common language runtime, you do not have to use the delete operator to release an object. The garbage collector does this for you automatically when the object is no longer being used by the application.

C++ developers might be accustomed to avoiding the use of short-term objects due to the associated cost of manually managing the memory for these objects. For managed short-term objects that are created and then go out of scope between collections, the cost of allocating and releasing memory is extremely low. In the .NET Framework, the garbage collector is actually optimized to manage objects with short lifetimes. When developing managed applications, it is appropriate to use short-term objects in situations where they simplify your code.

Visual Basic Developers

Visual Basic developers are accustomed to automatic memory management. The programming practices that you are familiar with will apply to the majority of the managed objects that you create in the .NET Framework. However, you should take special note of the suggested design pattern for a Dispose method to use when you create or use objects that encapsulate unmanaged resources.

The .NET Framework supports more languages that target the common language runtime than those mentioned here. Regardless of which managed language you use, the .NET Framework's garbage collector provides automatic memory management. It allocates and releases the memory for managed objects and, when necessary, executes Finalize methods and destructors to properly clean up unmanaged resources. Automatic memory management simplifies development by eliminating the common bugs that arise from manual memory management schemes.

See Also

Programming for Garbage Collection | Finalize Methods and Destructors