Vantaggi del codice non gestito [chiuso]

Question

Vantaggi del codice non gestito [chiuso]

#1 da (10 voti)
#2 da (1 voti)

0

tl; dr: Perché dovrei scegliere di scrivere / compilare codice ¹ non gestito

non gestito

Supponiamo che sto iniziando un nuovo progetto. Ho deciso di scrivere in un linguaggio simile a C, probabilmente uno di C, C ++, C # o Java. C # e Java sono gestiti (beh, Java viene eseguito nella JVM, ma si assume che sia la stessa cosa). I plugin GCC gestiti esistono (sebbene non ne abbia mai usato nessuno, quindi non so se sono utili). Il codice gestito ha molti vantaggi:

Non devi preoccuparti della raccolta dei rifiuti esplicita (che è poco pratica)
È molto più difficile perdere la memoria
È banale da implementare - basta scegliere la lingua corretta o i giusti flag del compilatore
- es. usa C # o usa MCP per GCC
Migliore interoperabilità se si sta eseguendo la compilazione in IL
Digitare sicurezza, controllo della matrice e dell'indicizzazione ecc.

Secondo me (che potrebbe essere sbagliato - e sto cercando di capire perché è sbagliato) è meglio usare quasi sempre il codice gestito. Esistono tuttavia linguaggi non gestiti e le lingue gestite hanno contrassegni non gestiti, pertanto è necessario scegliere alcuni motivi per il codice gestito. Quali sono i motivi?

Modifica: come indicato da Deduplicator, è possibile utilizzare un GC in codice non gestito (di terze parti o creato dall'utente). Questo porta a un'altra domanda correlata: tutti coloro che compilano codice C / C ++ nativo usano un GC? In caso contrario, quali sono i vantaggi per non utilizzare un GC?

^{1. Ai fini di questa domanda, sto prendendo in prestito la definizione di "Gestione" di John Bode (sotto) - qualsiasi cosa venga eseguita in una macchina virtuale, non solo la definizione Microsoft del codice gestito. Conosco Java come linguaggio "gestito" in quanto viene eseguito in una VM.}

garbage-collection managed-code

posta Jonny 01.12.2014 - 14:02

fonte

2 risposte

Leggi altre domande sui tag garbage-collection managed-code

Qual è la dimensione tipica del team di un'applicazione desktop C # complessa di mezzo milione di righe? [chiuso] Perché Perl è un linguaggio appropriato per CGI? [chiuso]

score 10 · Answer 1

Legacy: il codice nativo è molto più vecchio del codice gestito ¹ e ci sono ancora app native da mantenere;
Prestazioni: a parità di condizioni, il codice nativo dovrebbe essere più veloce e avere un ingombro di memoria inferiore rispetto al codice gestito (le cose sono raramente uguali e, per le attività legate all'I / O, la differenza è trascurabile); inoltre, la garbage collection non deterministica può giocare all'inferno con il codice in tempo reale;
Violazioni di sistema o hardware - il codice nativo può avere accesso a chiamate o librerie di sistema che il codice gestito non possiede (come per l'elaborazione parallela o l'elaborazione vettoriale, anche se immagino che la maggior parte delle lingue gestite dovrebbe essere in grado di esporre un'API per tali operazioni);
Nessuna VM disponibile: potresti mirare a un sistema per il quale nessuna VM è stata sviluppata o non dispone delle risorse per eseguire il codice gestito (come un microcontrollore o un altro sistema incorporato); inoltre, il sistema di destinazione potrebbe non aver bisogno delle funzionalità di una VM completa (prevalentemente attività legate alla CPU, I / O limitato, ecc.).

Lavoro esclusivamente con codice nativo (C ++ su Linux). Non c'è alcuna ragione oltre l'inerzia che non possiamo usare il codice gestito, ma per i nostri scopi funziona piuttosto bene. Dato che eseguiamo diverse centinaia di istanze client su un singolo server, potremmo utilizzare ogni ciclo che possiamo ottenere.

^{1. Con il quale intendo tutto ciò che viene eseguito in una macchina virtuale, non solo la definizione Microsoft del codice gestito. Conosco Java come linguaggio "gestito" in quanto viene eseguito in una VM.}

score 1 · Answer 2

Molto è l'inerzia. C è diventato la lingua franca dei computer. Praticamente ogni architettura di computer, non importa quanto oscura o esotica, ha un compilatore C. Praticamente ogni SO definisce la sua interfaccia binaria per le chiamate di sistema e le librerie collegate dinamicamente in termini di C. Le lingue di livello più alto hanno un meccanismo per chiamare il codice C. Pertanto, se si desidera che una libreria sia utilizzabile nella più ampia varietà possibile di hardware e linguaggi di programmazione, è necessario scriverla in C. Se non necessariamente la si deve eseguire su ogni singola architettura di computer, ma si desidera comunque che sia utilizzabile praticamente da tutte le lingue, è possibile scriverlo in un linguaggio di livello superiore ma fornire un'interfaccia C.

Sulla stessa falsariga, c'è facilità di interoperabilità. Uno dei motivi per usare C ++ è che è quasi un superset di C molto rigido, quindi non è necessario fare molto di tutto per usare il codice C esistente o avvolgere il proprio codice in un'interfaccia C.

Per un codice estremamente intensivo per le prestazioni e l'uso intensivo della matrice, potrebbe essere necessario utilizzare un accesso di array non controllato, che è qualcosa che i linguaggi di livello superiore non forniscono (oltre che attraverso il codice C) poiché si ottiene un comportamento indefinito se ti sbagli.

Un altro motivo per usare una lingua con allocazione manuale della memoria è scrivere un software estremamente sicuro, affidabile, in tempo reale. Ad esempio, gli standard di codifica della Jet Propulsion Labs della NASA per C proibiscono la ricorsione e l'allocazione dinamica della memoria dopo l'inizializzazione, quindi che possono garantire staticamente un limite superiore all'utilizzo della memoria e al tempo di allocazione / deallocazione. Tuttavia, esistono algoritmi di garbage collection in tempo reale che garantiscono prestazioni prevedibili, quindi non è impossibile scrivere software prevedibile nei linguaggi di livello superiore. Forse non c'è nessuna combinazione di adeguate implementazioni linguistiche di livello superiore e strumenti di analisi statica disponibili per l'hardware e il sistema operativo che usano.