Given that C# has the unsafe keyword, are there situations in which it would still be beneficial to interoperate with C libraries?

I could see the need for very fast number crunching, graphical manipulation or matrix operations, using pre-existing C libraries. But is there a use case for writing greenfield DLL's in, say, C99, and interoperating with them from C#?

I imagine that there might be edge cases where dropping down to C (in the sense that it is closer to the metal) would be the only way to get the needed performance characteristics.

4 Answers
4

Can do real time code with C. Not that windows is the best platform for it. But I have done realtime control systems with it. It would be nice to do it in C#, and most of the time it is predictable, but not always, and that's killer for RT systems.

Portability of C code over a number of platforms ( not just linux / windows, but any number of embedded systems ). I use things like encryption and compression from windows to embedded devices, rather than having a C and C# version of the code, easier to have one library with C# interop.

Ah, so basically you obtain complete control over memory allocation and disposal (i.e. you don't have to worry about indeterminate garbage collection). But there are ways to moderate that problem in C#, right?
–
Robert HarveyMar 21 '13 at 21:50

4

You've basically described when would you use C over C#. But that's not the question, the question is about interop, and you haven't really addressed that, I think.
–
svickMar 22 '13 at 1:03

First, unsafe is useful for a lot more than C interop. For example, doing image analysis with actual pixel data can be horribly slow while in "safe" mode. Flip over to unsafe mode, and doing the same work with direct access to the image buffer, is an order of magnitude faster.

Doing wholesale development in C/C++ for inclusion in a .Net project can certainly make sense, but it all comes down to performance. The classic advice would be to write the entire application in your language of choice, then profile. When you find a critical section of code that takes 50%+ of processing time and cannot be realistically tuned anymore while using a managed language, then re-implement that one routine in C and integrate.

A real life example: I was prototyping a path finding algorithm. After showing it worked with C#, I needed to make it fast enough to run many times a second. I had already built up some nice support UI in C# that showed all of the factors used for routing decisions, the results, etc. So I reimplemented the core part of the routing algorithm in C++. If I had started in C++, I doubt I would have gotten as far.

But is there a use case for writing greenfield DLL's in, say, C99, and interoperating with them from C#?

The main use case I see is when you are going to write a special lib which is targeted for many platforms where C or C99 is available, but C# is not or only for a few of them ("C#" may be not available for organizational reasons, not just pure technical ones).

Another use case is when you have an expert in some field (for example, an expert about a specific hardware), and he has the task to code some of his expert knowledge into a library, but that expert has 30 years of experience in C but none in C#.

One thing to consider: "100% greenfield" is a very rare situation today. For most kind of problems, at least partial solutions exist, or similar solutions which can be re-used when modified. So using C makes a whole lot of sense when you have to build something new on an existing C code base.

For me, greenfield DLL's would be something like ad-hoc equations or transforms that can be plugged into a real-time system. (which are still done in C where I work).
–
Robert HarveyMar 22 '13 at 18:53

@RobertHarvey - I think that you could substitute "consistency" instead of "SME knows C" in Doc's answer and have the same meaning. And as Keith implied in his answer, if you're writing for a hard real-time system then you may simply want the assurances that a C library would provide.
–
GlenH7Mar 22 '13 at 18:55

Yes, for interfacing with legacy software. I had to create an interop DLL that could be consumed by my legacy C application to take advantage of technology that was not available when my toolkit was invented.