The final chapter, which is the next chapter, pertains to unsafe code, which is an ominous name. What developer wants to purposely write unsafe code? In .NET, unsafe code really means potentially unsafe code, which is code or memory that exists outside the normal controls of the CLR. For this reason, developers should approach unsafe code with caution.
Developers have access to raw pointers in C#, which are called pinned pointers. They are Cstyle pointers. You can use pointer operators, such as * and &, with these pointers. Pointers should be avoided because they interrupt the normal operation of the GC. How-ever, not secure pointers are sometimes necessary. For example, porting algorithms that rely heavily on pointers is one situation in which not secure pointers are beneficial.
Managed developers must sometime call unmanaged routines. Although the breadth of the .NET FCL is expanding quickly, there is considerable system behavior that still resides out-side its realm. In addition, many third-party routines are not managed—particularly legacy applications. Finally, some code will never be managed for performance or other reasons. Interoperability allows managed developers to build bridges back to managed code. You can call unmanaged code from a managed routine. Conversely, you can call managed code from unmanaged routines.