Quali situazioni sono appropriate per l'interoperabilità da C # a C?

Ci sono un paio di cose che C ha su C #.

Può fare codice in tempo reale con C. Non che Windows sia la migliore piattaforma per questo. Ma ho fatto i sistemi di controllo in tempo reale con esso. Sarebbe bello farlo in C #, e la maggior parte delle volte è prevedibile, ma non sempre, e questo è un killer per i sistemi RT.

Portabilità del codice C su un certo numero di piattaforme (non solo linux / windows, ma qualsiasi numero di sistemi embedded). Uso elementi come la crittografia e la compressione da Windows a dispositivi incorporati, piuttosto che avere una versione C e C # del codice, più facile avere una libreria con C # interop.

Innanzitutto, unsafe è utile per molto più dell'interop di C. Ad esempio, l'analisi delle immagini con i dati reali dei pixel può essere terribilmente lenta in modalità "sicura". Passa alla modalità non sicura, e facendo lo stesso lavoro con l'accesso diretto al buffer delle immagini, è più veloce di un ordine di grandezza.

Fare lo sviluppo all'ingrosso in C / C ++ per l'inclusione in un progetto .Net può certamente avere senso, ma tutto si riduce alle prestazioni. Il consiglio classico sarebbe quello di scrivere l'intera applicazione nella lingua prescelta, quindi nel profilo. Quando trovi una sezione critica di codice che impiega il 50% in più del tempo di elaborazione e non può più essere ottimizzata realisticamente mentre si utilizza un linguaggio gestito, quindi reimplementare quella routine in C e integrarla.

Un esempio di vita reale: stavo prototipando un algoritmo di individuazione dei percorsi. Dopo aver mostrato che funzionava con C #, avevo bisogno di renderlo abbastanza veloce da girare molte volte al secondo. Avevo già creato una bella interfaccia utente di supporto in C # che mostrava tutti i fattori utilizzati per le decisioni di routing, i risultati, ecc. Quindi ho reimplementato la parte principale dell'algoritmo di routing in C ++. Se avessi iniziato in C ++, dubito che sarei arrivato fino a qui.

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

Il caso d'uso principale che vedo è quando scriverai una lib speciale che è mirata per molte piattaforme dove C o C99 è disponibile, ma C # non lo è o solo per alcune di esse ("C #" potrebbe non essere disponibile per motivi organizzativi, non solo puramente tecnici).

Un altro caso d'uso è quando hai un esperto in un campo (per esempio, un esperto su un hardware specifico), e ha il compito di codificare alcune delle sue conoscenze specialistiche in una biblioteca, ma quell'esperto ha 30 anni di esperienza in C ma nessuna in C #.

Una cosa da considerare: "il 100% greenfield" è una situazione molto rara oggi. Per la maggior parte dei problemi, esistono almeno soluzioni parziali o soluzioni simili che possono essere riutilizzate una volta modificate. Quindi usare C ha molto senso quando devi creare qualcosa di nuovo su una base di codice C esistente.

Sì, per l'interfaccia con il software legacy. Ho dovuto creare una DLL di interoperabilità che potesse essere utilizzata dalla mia applicazione C legacy per sfruttare la tecnologia che non era disponibile quando il mio toolkit è stato inventato.