Should you use pointers (unsafe code) in C#?

Question

Should you use pointers in your C# code? What are the benefits? Is it recommend by The Man (Microsoft)?

Answer 1

I used unsafe code to use impersonation to allow services access to network shares. It is not a problem if you know what you're doing.

Answer 2

You should use them if you need them; mostly this will be when dealing with some tricky interop scenarios (for example when I wrote a managed wrapper for DPAPI in .NET 1.0 they were needed) but very occasionally it might be to improve performance (after profiling!) by using stackalloc or similar.

It is recommended by Microsoft in as much as they are the designers of C#, and they made the decision to add the capability to write unsafe code in it. You can see from the choice of keyword and the requirement to delineate the methods/classes in which you write it using the keyword, that it isn't designed to be the de-facto implementation choice.

Answer 3

Do it if it makes your code shorter and clearer.

"Follow your inclinations with due regard to the policeman round the corner." WSM

Answer 4

I would say the main issues are:-

• Unsafe code is not verifiable. This means that the code can only be ran by a user from an entirely trusted context, thus if you ever need a user to run the code from anywhere less than entirely trusted (e.g. a network share not configured to be so), you're screwed.
• Lack of verifiability (hm not sure if that's actually a word) also means you could potentially mess up memory in your program. You are potentially bringing whole classes of bugs back into your application - buffer overruns, dangling pointers, yada yada yuck yuck. not to mention being potentially able to corrupt data structures in memory without realising when your pointer goes weird.
• If you want your unsafe code to access managed objects you need to 'pin' them. This means the GC is not allowed to move your object around in memory and thus the managed heap can become fragmented. This has performance implications; therefore it's always important to determine whether any potential perf gain isn't outweighed by this issue.
• Your code becomes harder to understand for programmers not used to the unmanaged approach. They may then be more liable to shoot their foot off with some of the 'freedom' unsafe code gives them.
• You become able to write un-type-safe code; this really rather eliminates a lot of the advantage of a nice warm fuzzy managed language. Now you can encounter horrible type safety issues. Why take that step backwards?
• It makes your code uglier.

I'm sure there's more that could be added to the list; in general, as others' have said - avoid unless you have to.e.g. calling an unmanaged method via p/invoke which requires some special pointer funking. Even then the marshaller will mostly prevent the need for it, mostly.

'The man' also say avoid unless necessary, basically.

Oh, nice article about pinning here on MSDN by the way.

Answer 5

I can't remember ever having to do so - but I haven't done much interop. That's the most common application, I believe: calling into native code. There are a very few times where using pointers allows you to optimise some code, but it's pretty rare in my experience.

If it's any guide, I consider myself to be pretty experienced in C# but if I had to do any unsafe code I'd have to consult the spec/books/MSDN to guide me. Of course there will be plenty of people who are happy with unsafe code but less familiar with (say) query expressions...