¿Qué situaciones son apropiadas para la interoperabilidad de C # a C?

Dado que C # tiene la unsafepalabra clave, ¿hay situaciones en las que aún sería beneficioso interactuar con las bibliotecas de C?

Pude ver la necesidad de un rápido procesamiento de números, manipulación gráfica u operaciones matriciales, utilizando bibliotecas C preexistentes. Pero, ¿hay un caso de uso para escribir archivos DLL nuevos en, por ejemplo, C99, e interoperar con ellos desde C #?

Me imagino que podría haber casos extremos en los que bajar a C (en el sentido de que está más cerca del metal) sería la única forma de obtener las características de rendimiento necesarias.

Hay un par de cosas que C tiene sobre C #.

Puede hacer código en tiempo real con C. No es que Windows sea la mejor plataforma para ello. Pero he hecho sistemas de control en tiempo real con él. Sería bueno hacerlo en C #, y la mayoría de las veces es predecible, pero no siempre, y eso es asesino para los sistemas RT.

Portabilidad del código C sobre varias plataformas (no solo Linux / Windows, sino cualquier cantidad de sistemas integrados). Utilizo cosas como el cifrado y la compresión desde Windows a dispositivos integrados, en lugar de tener una versión C y C # del código, es más fácil tener una biblioteca con interoperabilidad C #.

Primero, unsafees útil para mucho más que la interoperabilidad C. Por ejemplo, hacer análisis de imágenes con datos de píxeles reales puede ser terriblemente lento mientras está en modo "seguro". Voltear al modo inseguro y hacer el mismo trabajo con acceso directo al búfer de imagen es un orden de magnitud más rápido.

Hacer un desarrollo mayorista en C / C ++ para incluirlo en un proyecto .Net ciertamente puede tener sentido, pero todo se reduce al rendimiento. El consejo clásico sería escribir la aplicación completa en el idioma de su elección, luego el perfil. Cuando encuentre una sección crítica de código que requiera más del 50% del tiempo de procesamiento y que ya no pueda ajustarse de manera realista mientras usa un lenguaje administrado, vuelva a implementar esa rutina en C e integre.

Un ejemplo de la vida real: estaba creando prototipos de un algoritmo de búsqueda de ruta. Después de mostrar que funcionaba con C #, necesitaba hacerlo lo suficientemente rápido como para correr muchas veces por segundo. Ya había creado una buena interfaz de usuario de soporte en C # que mostraba todos los factores utilizados para las decisiones de enrutamiento, los resultados, etc. Así que reimplementé la parte central del algoritmo de enrutamiento en C ++. Si hubiera comenzado en C ++, dudo que hubiera llegado tan lejos.

Pero, ¿hay un caso de uso para escribir archivos DLL nuevos en, por ejemplo, C99, e interoperar con ellos desde C #?

El principal caso de uso que veo es cuando vas a escribir una lib especial que está dirigida a muchas plataformas donde C o C99 está disponible, pero C # no está disponible o solo para algunas de ellas ("C #" puede no estar disponible para la organización razones, no solo técnicas puras).

Otro caso de uso es cuando tiene un experto en algún campo (por ejemplo, un experto en un hardware específico), y tiene la tarea de codificar parte de su conocimiento experto en una biblioteca, pero ese experto tiene 30 años de experiencia en C pero ninguno en C #.

Una cosa a considerar: "100% greenfield" es una situación muy rara hoy en día. Para la mayoría de los problemas, existen al menos soluciones parciales o soluciones similares que pueden reutilizarse cuando se modifican. Entonces, usar C tiene mucho sentido cuando tienes que construir algo nuevo en una base de código C existente.

Sí, para interactuar con software heredado. Tuve que crear una DLL de interoperabilidad que podría ser consumida por mi aplicación C heredada para aprovechar la tecnología que no estaba disponible cuando se inventó mi kit de herramientas.