Domanda

A volte è difficile descrivere alcune delle cose che "noi programmatori" possono pensare che siano semplici per i non programmatori e i tipi di gestione.

...

Come descriveresti la differenza tra Managed Code (o Java Byte Code) e Unmanaged / Native Code rispetto a un non programmatore?

È stato utile?

Soluzione

Managed Code == " Mansion House con un intero staff o maggiordomi, cameriere, cuochi e amp; Giardinieri per mantenere il posto piacevole "

Codice non gestito == " Dove vivevo all'università "

Altri suggerimenti

pensa alla tua scrivania, se la ripulisci regolarmente, c'è spazio per sederti su ciò su cui stai effettivamente lavorando di fronte a te. se non lo ripulisci, rimani senza spazio.

Quello spazio equivale a risorse del computer come RAM, disco rigido, ecc.

Il codice gestito consente al sistema di scegliere automaticamente quando e cosa ripulire. Il codice non gestito rende il processo "manuale" - in quanto il programmatore deve dire al sistema quando e cosa ripulire.

Sono stupito da ciò che emerge da questa discussione (beh, non proprio ma retoricamente). Lasciami aggiungere qualcosa, anche se sono in ritardo.

Macchine virtuali (VM) e Garbage Collection (GC) hanno decenni e due concetti separati . Esistono linguaggi compilati in codice nativo raccolti con immondizia, anche questi da decenni (esempio canonico: ANSI Common Lisp ; beh, esiste almeno un < forte> tempo di compilazione spazzatura raccolto linguaggio dichiarativo, Mercurio - ma a quanto pare le masse urlano in lingue simili a Prolog).

Le VM basate su codice byte improvvisamente GC sono una panacea per tutte le malattie IT. Sandboxing di file binari esistenti (altri esempi qui , qui e qui )? Principio della minima autorità (POLA) / sicurezza basata sulle capacità ? Binary slim (o la sua variante moderna SafeTSA )? Inferenza della regione ? No, signore: Microsoft & amp; Sun non ci autorizza a pensare solo a tali perversioni. No, riscrivi meglio il nostro intero stack software per questa meravigliosa (???) nuova lingua (???) & # 167; / API. Come dice uno dei nostri host, è Fire and Motion ancora una volta.

& # 167; Non essere sciocco: so che C # non è l'unico linguaggio che ha come target .Net / Mono, è un iperbole .

Modifica: è particolarmente istruttivo guardare commenti a questa risposta di S.Lott alla luce delle tecniche alternative per la gestione della memoria / sicurezza / mobilità del codice che ho sottolineato.

Il mio punto è che le persone non tecniche non devono preoccuparsi dei tecnicismi a questo livello di dettaglio.

D'altra parte, se sono colpiti dal marketing Microsoft / Sun, è necessario spiegare loro che vengono ingannati: le VM basate su codice byte GCed non sono questa novità come sostengono, non risolvono magicamente ogni Esistono problemi IT e alternative a queste tecniche di implementazione (alcune sono migliori).

Modifica 2: Garbage Collection è una tecnica di gestione della memoria e, come ogni tecnica di implementazione, deve essere compresa per essere utilizzata correttamente. Guarda come, presso ITA Software, bypassano GC per ottenere buone prestazioni :

  

4 - Poiché disponiamo di circa 2 concerti di dati statici, dobbiamo accedere rapidamente   usiamo il codice C ++ per mappare la memoria enorme   file contenenti strutture senza puntatore C.   (di voli, tariffe, ecc.) e quindi   accedi a questi da Common Lisp utilizzando   accessi ai dati stranieri. Un campo struct   l'accesso si compila in due o tre   istruzioni, quindi non c'è davvero   qualsiasi esibizione. penalità per l'accesso   C piuttosto che oggetti Lisp. Facendo   questo, manteniamo la spazzatura di Lisp   raccoglitore dalla visualizzazione dei dati (a   Lisp, ogni puntatore a un oggetto C è   solo un fixnum, anche se lo facciamo spesso   avvolgere temporaneamente questi puntatori   Lisp oggetti da migliorare   debuggability). Le nostre immagini Lisp lo sono   quindi solo circa 250 mega di   & Quot; lavoro " strutture di dati e codice.

     

...

     

9 - Possiamo fare 10 secondi di calcolo Lisp su una scatola da 800mhz e contro   meno di 5k di dati. Questo è perché   pre-allociamo tutte le strutture dati che abbiamo   bisogno e morire per domande che superano   loro. Questo può rendere molti Lisp   i programmatori si arrabbiano, ma con un 250 meg   immagine e vincoli in tempo reale, noi   non può permettersi di generare immondizia . Per   esempio, piuttosto che usare contro, noi   usa " contro! " ;, che prende le celle da un   array di 10.000.000 di celle che abbiamo   preallocato e che viene ripristinato   ogni query.

Modifica 3: (per evitare incomprensioni) GC è meglio che armeggiare direttamente con i puntatori? Il più delle volte, certamente, ma ci sono alternative a entrambi . È necessario disturbare utenti con questi dettagli? Non vedo alcuna prova che questo sia il caso, oltre a dissipare un po 'di campagna pubblicitaria quando necessario.

Sono abbastanza sicuro che l'interpretazione di base sia:

  • Gestito = pulizia delle risorse gestita da runtime (ad es. Garbage Collection)
  • Non gestito = ripulisci dopo te stesso (ovvero malloc & amp; free )

Forse confrontalo con gli investimenti nel mercato azionario.

Puoi acquistare e vendere azioni da solo, cercando di diventare un esperto in ciò che offrirà il miglior rischio / rendimento - oppure puoi investire in un fondo gestito da un "esperto"; chi lo farà per te - a costo di perdere un po 'di controllo, e forse qualche commissione. (Devo ammettere che sono più un fan dei fondi tracker, e gli esperti del mercato azionario "non sono stati esattamente brillanti di recente, ma ....)

Ecco la mia risposta:

Managed (.NET) o Byte Code (Java) ti faranno risparmiare tempo e denaro.

Ora confrontiamo i due:

Codice non gestito o nativo

È necessario eseguire l'allocazione e la pulizia delle risorse (RAM / memoria). Se si dimentica qualcosa, si finisce con quella che viene chiamata "perdita di memoria" che può causare l'arresto anomalo del computer. Una perdita di memoria è un termine per quando un'applicazione inizia a consumare (consumando) RAM / memoria ma non lasciarla andare in modo che il computer possa utilizzarla se per altre applicazioni; alla fine ciò causa l'arresto anomalo del computer.

Per eseguire l'applicazione su diversi sistemi operativi (Mac OSX, Windows, ecc.) è necessario compilare il codice appositamente per ciascun sistema operativo ed eventualmente modificare un sacco di codice specifico del sistema operativo in modo che funzioni su ogni Sistema operativo.

.NET Managed Code o Java Byte Code

Tutta l'allocazione e la pulizia delle risorse (RAM / Memoria) vengono eseguite per te e il rischio di creare "Perdite di memoria" è ridotto al minimo. Ciò consente più tempo per codificare le funzionalità invece di spenderle nella gestione delle risorse.

Per eseguire la tua applicazione su diversi sistemi operativi (Mac OSX, Windows, ecc.) devi solo compilare una volta, e funzionerà su ognuno di essi fintanto che supportano il Framework dato che l'app viene eseguita su ( .NET Framework / Mono o Java).

In breve

Lo sviluppo con .NET Framework (Managed Code) o Java (Byte Code) rende complessivamente più economico la creazione di un'applicazione in grado di indirizzare più sistemi operativi con facilità e di dedicare più tempo alla creazione di funzionalità avanzate anziché banali compiti di gestione della memoria / delle risorse.

Inoltre, prima che qualcuno sottolinei che .NET Framework non supporta più sistemi operativi, devo sottolineare che tecnicamente Windows 98, WinXP 32-bit, WinXP 64-bit, WinVista 32-bit, WinVista 64- bit e Windows Server sono tutti sistemi operativi diversi, ma la stessa app .NET verrà eseguita su ciascuno. E c'è anche il Mono Project che porta .NET su Linux e Mac OSX.

Il codice non gestito è un elenco di istruzioni che il computer deve seguire. Il codice gestito è un elenco di attività per il computer che il computer è libero di interpretare da solo su come eseguirle.

La grande differenza è la gestione della memoria. Con il codice nativo, devi gestire tu stesso la memoria. Questo può essere difficile ed è la causa di molti bug e molto tempo di sviluppo impiegato per rintracciare quei bug. Con il codice gestito, hai ancora problemi, ma molti meno e sono più facili da rintracciare. Ciò significa normalmente meno software difettoso e meno tempo di sviluppo.

Esistono altre differenze, ma la gestione della memoria è probabilmente la più grande.

Se fossero ancora interessati, potrei menzionare quanti exploit provengono da sovraccarichi del buffer e che non lo si ottiene con il codice gestito, o che il riutilizzo del codice è ora facile o che non è più necessario gestire COM (se sei fortunato comunque). Probabilmente starei lontano dalla COM, altrimenti mi lancerei in una tirata per quanto sia terribile.

È come la differenza tra giocare a biliardo con e senza paraurti lungo i bordi. A meno che tu e tutti gli altri giocatori non facciate sempre dei tiri perfetti, avete bisogno di qualcosa per tenere le palle sul tavolo. (Ignora rimbalzi intenzionali ...)

O usa il calcio con i muri anziché le linee laterali e le linee di fondo, o il baseball senza backstop, o l'hockey senza rete dietro l'obiettivo, o la NASCAR senza barriere, o il calcio senza caschi ...)

" Il termine specifico codice gestito è particolarmente diffuso nel mondo Microsoft. "

Dal momento che lavoro nel mondo MacOS e Linux, non è un termine che uso o incontro.

Brad Abrams " Che cos'è il codice gestito " post sul blog ha una definizione che dice cose come "quot. Common Language Runtime".

Il mio punto è questo: potrebbe non essere appropriato spiegarlo affatto. Se si tratta di un bug, un hack o una soluzione alternativa, non è molto importante. Certamente non abbastanza importante da elaborare una descrizione sofisticata dei laici. Potrebbe svanire con la prossima versione di alcuni lotti di prodotti MS.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top