C# memory management: unsafe keyword and pointers

As already mentioned by Conrad, there are some situations where unsafe access to memory in C# is useful. There are not as many of them, but there are some:

• Manipulating with Bitmap is almost a typical example where you need some additional performance that you can get by using unsafe.

• Interoperability with older API (such as WinAPI or native C/C++ DLLs) is another area where unsafe can be quite useful – for example you may want to call a function that takes/returns an unmanaged pointer.

On the other hand, you can write most of the things using Marshall class, which hides many of the unsafe operations inside method calls. This will be a bit slower, but it is an option if you want to avoid using unsafe (or if you’re using VB.NET which doesn’t have unsafe)

Positive consequences:
So, the main positive consequences of the existence of unsafe in C# is that you can write some code more easily (interoperability) and you can write some code more efficiently (manipulating with bitmap or maybe some heavy numeric calculations using arrays – although, I’m not so sure about the second one).

Negative consequences: Of course, there is some price that you have to pay for using unsafe:

• Non-verifiable code: C# code that is written using the unsafe features becomes non-verifiable, which means that the your code could compromise the runtime in any way. This isn’t a big problem in a full-trust scenario (e.g. unrestricted desktop app) – you just don’t have all the nice .NET CLR guarantees. However, you cannot run the application in a restricted enviornment such as public web hosting, Silverlight or partial trust (e.g. application running from network).

• Garbage collector also needs to be careful when you use unsafe. GC is usually allowed to relocate objects on the managed heap (to keep the memory defragmented). When you take a pointer to some object, you need to use the fixed keyword to tell the GC that it cannot move the object until you finish (which could probably affect the performance of garbage collection – but of course, depending on the exact scenario).

My guess that if C# didn’t have to interoperate with older code, it probably wouldn’t support unsafe (and research projects like Singularity that attempt to create more verifiable operating system based on managed languages definitely disallow usnsafe code). However, in the real-world, unsafe is useful in some (rare) cases.