In this series, I’ll take a stab at explaining the different types of objects used in every day applications, how they are held in memory, and how they are eventually cleaned up. Along the way, I’ll hopefully clear up some of the haze that generally surrounds the stack, the heap, object finalization, memory leaks, “unmanaged resources,” the GC (garbage collector), and some other things. 

This is Part 1 of 4, covering managed and unmanaged code, and the stack. Part 2 will discuss the heap. Part 3 will cover boxing and unboxing, stucts and classes, nondeterministic finalization, IDisposable, and garbage collection. Part 4 will discuss buffer overruns, stack overflows, how to hack and Xbox, and a few best practices for memory-management-aware programming in .Net.

Type safety basically means using strongly-typed data to protect against nasty bugs caused by type errors. A “strong type” is a programming construct that imposes certain rules or restrictions on specific data and how the data can be used. A “type error” is a bug that only appears at runtime (as opposed to compile time), and can have a considerably undesirable impact on data – often it only appears when you discover that something has gone terribly wrong. So, we should always strive to write type-safe code.

Here is an example. The following method call would not be considered type safe: