|
|
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. |
|
Read more...
|
|
|
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: |
|
Read more...
|
|
|
For a web project in Visual Studio 2005, there is by default no project file. The folder structure alone is used to define what’s in the project. To compare: In non-web projects, Visual Studio project files manage the locations of referenced assemblies. When a non-web project is built, Visual Studio looks into the project file and looks through its list of referenced assemblies. For each one, it compares the version in the local obj directory with the one located at the hint path in the project file. If it’s different, then the project can copy down the new version before it continues to build. This is how the projects can manage when “project references” and other references change. |
|
Read more...
|
|
|
|
|