Perché non usare un codice sicuro non gestito in C #

C'è un'opzione in C # per eseguire il codice non selezionato. In genere non è consigliabile farlo, poiché il codice gestito è molto più sicuro e risolve molti problemi.

Tuttavia mi chiedo, se sei sicuro che il tuo codice non causerà errori e sai come gestire la memoria, perché (se ti piace il codice veloce) seguire i consigli generali?

Mi chiedo questo da quando ho scritto un programma per una videocamera, che ha richiesto una manipolazione bitmap estremamente veloce. Ho creato alcuni algoritmi grafici veloci e funzionano in modo eccellente sulle bitmap usando un codice non gestito.

Ora mi chiedo in generale, se sei sicuro di non avere perdite di memoria o rischi di arresti anomali, perché non utilizzare il codice non gestito più spesso?

PS: il mio background: sono entrato in questo mondo della programmazione e lavoro da solo (lo faccio per alcuni anni) e quindi spero che questa domanda di progettazione del software non sia così strana. Non ho davvero altre persone là fuori come un insegnante per chiedere queste cose.

Bene, è principalmente un caso del vecchio adagio

• Non ottimizzare
• (solo per esperti) Non ottimizzare ancora

Ma in realtà posso pensare a tre motivi principali per evitare codici non sicuri.

1. Bug : la parte critica della tua domanda è "se sei sicuro che il tuo codice non causerà errori". Bene, come puoi essere assolutamente sicuro? Hai usato un prover con metodo formale che ha garantito il tuo codice corretto? Una cosa è certa nella programmazione, ed è che avrai dei bug. Quando decolli di sicurezza, permetti a un nuovo tipo di bug di insinuarsi. Quando lasci che il garbage collector si occupi della memoria per te, molti problemi scompaiono.

2. Non sempre veloce come pensi : l'altro punto è: a seconda del problema, il guadagno potrebbe non essere così grande. Anche se non riesco a trovarli in questo momento, ricordo uno studio di Google che confronta la velocità di Java, Scala, Go e C ++. Una volta ottimizzato a terra, ovviamente C ++ era molto più veloce. Ma l'algoritmo programmato in modo "idiomatico" non era molto più veloce. Idiomatico nel senso che stavano usando la struttura standard e gli idiomi (contenitore stl, nessun anello non srotolato, ecc.). Microsoft ha fatto un esperimento simile con C # e C ++. Raymond Chen, uno dei migliori ingegneri Microsoft, ha dovuto scrivere la sua implementazione di std :: string per battere C #. (vedi: http://www.codinghorror.com/blog/2005/05/on-managed-code-performance-again.html) Per uno sforzo molto minore, hai ottenuto prestazioni abbastanza decenti nel codice gestito, quindi spesso non vale la pena.

3. Riutilizzabilità : il codice non sicuro può essere utilizzato solo in un ambiente completamente affidabile. Ad esempio, in un server ASP.NET, di solito non è possibile utilizzare un codice non sicuro, poiché sarebbe piuttosto semplice introdurre una vulnerabilità tramite buffer overflow. Un altro esempio sarebbe clickonce. O se si accede alla propria applicazione da una condivisione di rete. Quindi, se prevedi di utilizzare il tuo codice in una varietà di scenari di distribuzione, il codice non sicuro è fuori gioco.

Quindi in sostanza: è malvisto perché può introdurre bug inutili, potrebbe non avere alcun guadagno e ridurre la riusabilità del codice.

Ma se il tuo scenario lo richiede davvero per le prestazioni (e disponi di dati per dimostrarlo), sei un programmatore esperto che sa come gestire la memoria e il tuo codice verrà utilizzato in un ambiente controllato, quindi assicurati.

In un certo senso, il codice non gestito è una forma di pagamento: acquisti più velocemente con lo sforzo di sviluppo extra. In effetti, il codice non gestito richiede più tempo per lo sviluppo, il debug e la manutenzione. Farlo esattamente nel modo giusto è una sfida per la maggior parte dei partecipanti. In un certo senso, questo è simile alla programmazione in assembly: certo, puoi scrivere più potenza dalla tua CPU se scrivi in ​​assembly ^* , ma "spendi" molto più sforzo lungo quella strada.

A volte, la differenza nei tempi di sviluppo è molto significativa: giorni anziché ore. Tuttavia, la differenza nella velocità di esecuzione non è altrettanto drammatica. Ecco perché lo sviluppo di codice non gestito è riservato a situazioni simili a quella che hai descritto nel tuo post - implementazioni localizzate, autonome, di algoritmi affamati di risorse, come l'elaborazione audio e video.

In sostanza, la risposta alla tua domanda è simile alla risposta del perché tutti non guidano la Ferrari: è un'auto molto migliore, giusto? (Un) per fortuna, non tutti possono permetterselo.

Perché essere "sicuri" della correttezza o di qualsiasi altro vincolo in senso matematico (cioè se si ha una prova) è un problema molto difficile per i linguaggi imperativi. I programmi hanno spesso un numero di stati così elevato che non è possibile verificarli anche controllando ogni stato possibile. E creare una dimostrazione costruttiva non è qualcosa che puoi automatizzare.

Quindi il motivo è che le assicurazioni che l'esecuzione gestita fornisce molto spesso sovrastimano il piccolo guadagno in termini di prestazioni che otterresti con un codice non sicuro. Naturalmente, questo dipende anche dal caso d'uso specifico.

In breve, nulla ti impedisce di fare tutto ciò che funziona e di gestire bit e bulloni del tuo programma in ambiente C ++. Dato che sei abbastanza sicuro di poter gestire correttamente tutti i cerchi e le perdite di memoria senza garbage collector, allora sei il benvenuto a farlo in C ++ :)

Al contrario, C # presenta vantaggi nel fornire un ambiente di sviluppo sicuro / gestito e fortemente tipizzato per l'esecuzione sicura in .NET framework.

Il possibile back-draw della programmazione di codice non gestito è il tempo di sviluppo più lungo, allocazione del tempo per test dettagliati. Naturalmente otterrai velocità di elaborazione e maggiore controllo sul funzionamento del tuo software.

Pertanto, l'opzione per lavorare con codice non gestito in .NET Framework a partire da 4.0 è un'opzione per casi limite quando sei sicuro che potrebbe portare a guadagni rispetto al non usarlo ...