Introduction

Managed and unmanaged code describe who is responsible for executing code and managing low-level runtime services such as memory, type safety, and interop boundaries. The distinction is most familiar in the .NET world, where C# code normally runs under the Common Language Runtime while C or native C++ code runs directly as machine code without that runtime management layer.

What Managed Code Means

Managed code runs under a managed runtime. In .NET, that runtime is the CLR. Instead of your program being responsible for every low-level detail, the runtime provides services such as:

• garbage collection
• metadata and reflection
• exception handling infrastructure
• type verification
• runtime loading and JIT compilation

A simple C# example is managed code:

1using System;
2
3public class Program
4{
5    public static void Main()
6    {
7        string message = "hello";
8        Console.WriteLine(message.ToUpper());
9    }
10}

When this runs, the CLR is involved in loading assemblies, tracking objects, and eventually reclaiming memory.

What Unmanaged Code Means

Unmanaged code runs outside a managed runtime. Native C and C++ are the usual examples. The program is compiled into machine code for a target platform, and memory management is largely under programmer control.

1#include <stdio.h>
2#include <stdlib.h>
3
4int main(void) {
5    char *buffer = malloc(6);
6    if (buffer == NULL) {
7        return 1;
8    }
9
10    snprintf(buffer, 6, "hello");
11    printf("%s\n", buffer);
12    free(buffer);
13    return 0;
14}

Here the runtime does not garbage-collect buffer. The code must free it explicitly.

That does not mean unmanaged code has no runtime libraries at all. It means there is no managed execution environment taking responsibility for memory safety and related services the way the CLR or JVM would.

The Tradeoff Is Not "Good" Versus "Bad"

Managed code often improves developer productivity and safety. Unmanaged code often provides finer control over memory layout, ABI compatibility, and low-level performance characteristics.

Managed code is attractive when you want:

• fast application development
• fewer memory-management bugs
• safer library boundaries
• rich runtime tooling

Unmanaged code is attractive when you need:

• direct OS or hardware access
• compatibility with native libraries or drivers
• deterministic control over memory and layout
• a runtime model independent of a managed VM

That is why both models still exist.

Managed Code Is Still Compiled

A common misconception is that managed code is interpreted and unmanaged code is compiled. That is not the right distinction.

Managed languages such as C# are compiled too, but usually into an intermediate representation plus metadata. The managed runtime then loads and executes that code, often using just-in-time compilation.

So the more accurate distinction is:

• managed code is executed under a runtime that provides management services
• unmanaged code is compiled to native code and executed without that management layer

Interop Between The Two Worlds

Real systems often need both. A managed application may call native code through an interop boundary.

For example, a C# program can call a native DLL using DllImport.

1using System;
2using System.Runtime.InteropServices;
3
4public static class NativeMethods
5{
6    [DllImport("kernel32.dll")]
7    public static extern uint GetTickCount();
8}
9
10public class Program
11{
12    public static void Main()
13    {
14        Console.WriteLine(NativeMethods.GetTickCount());
15    }
16}

The calling code is managed, but the imported function is unmanaged. This is one reason the distinction matters in practice: crossing the boundary changes rules around marshalling, ownership, and error handling.

Memory Management Is The Usual Teaching Example

Memory management is the easiest way to see the difference, but it is not the only one.

In managed code:

• objects usually live on a managed heap
• the runtime tracks references
• garbage collection reclaims unused objects

In unmanaged code:

• allocation may be manual or custom
• object lifetime rules depend on the language and conventions
• pointer misuse can corrupt memory directly

Even in managed code, some resources still need explicit cleanup. File handles, sockets, and database connections are not purely "solve it with GC" resources. In .NET you still use using or Dispose patterns.

using var stream = System.IO.File.OpenRead("data.txt");
Console.WriteLine(stream.Length);

That is managed code, but it still performs explicit resource cleanup because the resource is external to ordinary memory reclamation.

Performance And Safety Nuance

It is tempting to say unmanaged code is always faster. That is too simplistic.

Unmanaged code can remove certain layers of overhead and allow lower-level optimization, but managed runtimes perform sophisticated optimizations too. The real difference is usually control, predictability, and access to low-level capabilities, not an automatic speed ranking.

Likewise, managed code is not magically safe. It simply offloads many classes of bugs to runtime checks and managed abstractions.

Common Pitfalls

• Thinking managed code means "not compiled".
• Assuming unmanaged code means "no runtime library exists at all".
• Treating garbage collection as a replacement for all resource cleanup.
• Assuming unmanaged code is always faster without measuring the actual workload.
• Ignoring interop costs when a managed program frequently calls native code.

Summary

• Managed code runs under a runtime such as the CLR that provides services like GC and type management.
• Unmanaged code runs as native code without that managed execution layer.
• The key distinction is execution and responsibility boundaries, not whether the code was compiled.
• Managed code improves safety and tooling; unmanaged code gives tighter low-level control.
• Many real applications use both through interop.