Perché sono molte Vm scritto in C quando sembrano C++ caratteristiche?

Question

Ho notato che alcuni non così vecchio VM lingue come Lua, NekoVM, e la Pozione scritto in C.

Sembravano reimplementando molti C++ caratteristiche.

C'è un beneficio per la scrittura in C e non C++?

Answer 1

Ho qualche informazione su Lua.

• Lua è scritto in puro ANSI C e compila su qualsiasi piattaforma ANSI senza errori e nessun avviso. Così Lua funziona su quasi tutte le piattaforme nel mondo , comprese le cose come fotocamere Canon PowerShot . E 'molto più difficile ottenere C ++ per funzionare su piattaforme embedded po' strano.

• Lua è un ad alte prestazioni VM, e perché C non può esprimere le chiamate di metodo (che potrebbe essere virtuale o non potrebbe) e l'overloading degli operatori, è molto più più facile da prevedere le prestazioni del codice C solo guardando il codice. C ++, in particolare con il modello di biblioteca, lo rende un po 'troppo facile da bruciare risorse senza rendersene conto. (A piena attuazione del Lua tra cui non solo VM, ma le librerie si inserisce nel 145K di codice oggetto x86. L'intero linguaggio si inserisce anche in un piccolo 256K di cache, che si trova a L2 su Intel i7 e L1 su chip più anziani. A meno che non si sa davvero che cosa si sta facendo, è molto più difficile scrivere ++ C che compila a qualcosa di questo piccolo.)

Si tratta di due buoni motivi per scrivere una VM in C.

Answer 2

  

E sembrava che stavano reimplementare molte funzioni C ++.

Stai suggerendo che è più facile da implementare il polimorfismo in C ++ invece che C? Penso che tu sia sbaglia di grosso.

Se si scrive una macchina virtuale in C ++, si potrebbe non implementare il polimorfismo in termini di polimorfismi C ++ 's. Faresti tira il vostro tavolo virtuale che mappa i nomi delle funzioni di puntatori, o qualcosa del genere.

Answer 3

La gente è abituata a C. Devo ammettere che sono più propensi a scrivere C per i miei progetti, anche se ho scritto C ++ dal Cfront 1.0.

Se si vuole il controllo completo sulle cose, C è un po 'più facile.

Answer 4

Una risposta ovvia è l'interoperabilità. Qualsiasi linguaggio tempo X ha per richiamare le funzioni definite nel linguaggio Y, è solito fare in modo che X o Y è C (il linguaggio C, che è)

C ++ non definisce un ABI, in modo da chiamare il codice C ++ da un'altra lingua è un po 'difficile da fare portabile. Ma chiamando codice C è quasi banale. Ciò significa che almeno una parte della vostra macchina virtuale è destinata probabilmente ad essere scritto in C, e allora perché non essere coerenti e scrivere l'intera cosa in C?

Un altro vantaggio di C è che è semplice. Tutti possono leggere, e ci sono un sacco di programmatori per aiutarti a scrivere esso. C ++ è, nel bene e nel male, molto di più di un linguaggio esperti. Si può fare un sacco di cose impressionanti in C ++, ed è possibile risparmiare un sacco di lavoro, ma ci sono anche un minor numero di programmatori che sono davvero bravi a farlo.

Answer 5

E 'molto più difficile essere "buono" in C ++, e fino a quando uno è bravo a farlo avranno un sacco di bug e problemi. Ora, soprattutto quando si lavora su grandi progetti con molte persone, la possibilità che uno di loro non ci sarà abbastanza buono è molto più grande, in modo da codificare il progetto in C è spesso meno rischiosa. Ci sono anche problemi di portabilità - codice C è molto più facile porta attraverso compilatori di C ++

.

Answer 6

Lua ha anche molte caratteristiche che sono molto facili da implementare in Lisp, quindi perché non ci vuole che come base? Il punto è che C è poco più di codice assemblatore glorificato con solo un sottile strato di astrazione. E 'come una tabula rasa un po' lucido, su cui è possibile costruire le vostre astrazioni di livello superiore. C ++ è un tale edificio. Lua è un altro edificio, e se ha dovuto usare astrazioni C ++, che avrebbe dovuto piegare il suo intento intorno alla struttura esistente C ++. A partire dalla tabula rasa, invece ti dà la libertà di costruire come si desidera.

Answer 7

In molti casi, il codice in C potrebbe essere molto più veloce di C ++. Per esempio la maggior parte delle funzioni della libreria stdio.c sono più veloci di iostream. scanf è più veloce di cin, printf è più veloce di cout ecc.

e macchine virtuali richiedono prestazioni elevate, in modo da codice C ha perfettamente senso, anche se i programmi sarebbero molto probabilmente richiederà più tempo per svilupparsi.

Answer 8

C ++ è implementato in C. Ho il sospetto che tutti stavano seguendo l'approccio C ++.

Anche se moderni compilatori C ++ saltare (o nascondere) il C ++ esplicito alla traduzione C come un passo discreto, il linguaggio C ++ ha peculiarità che derivano dall'implementazione C sottostante.

Due esempi.

• Puntatori, oltre ai riferimenti è del tutto a causa di C. I riferimenti sono sufficienti, e questo è il modo in cui Java, Python e Ruby tutti i lavori.

• Le classi non sono oggetti di prima classe che esistono in fase di esecuzione perché la classe è soltanto un modo per definire gli attributi e funzioni metodo nel codice C sottostante. oggetti di classe esistono in fase di esecuzione in Java, Python e Ruby, e possono essere manipolati.

Answer 9

Solo una nota a margine, si dovrebbe guardare in CLR (Rotore-incarnazione) e sorgenti Java e si nota che è molto più C++come C piuttosto che moderno o buona C++.Così si ha un parallelo c'è un effetto collaterale di astrazione per i giocattoli e rendendo media-prestazioni felice per il pubblico in lingue gestite.

Essa contribuisce anche a evitare le insidie di ingenui C++ utilizzo.Eccezioni e tutte le altre cose (bit di David al boost di consulenza a calci e anche di più, mentre noi costruiamo sequencer e campionamento audio prima ancora che avesse un lavoro :) sono un problema troppo..

Python integrazione è un'altra questione, e ha una brutta storia in boost per esempio..Ma per tipi di dati primitivi e interfacce/interoperabilità e la macchina astrazione, beh, è abbastanza chiaro che non c'è niente di C.Nessun compilatore problemi, e ancora bootstrap molte cose prima di arrivare a qualcosa di così influente come è/era/sarà.

Stepanov ha riconosciuto il successo quando ha inchiodato STL, e Bjarne inchiodato con i modelli..Queste sono le tre cose che sempre vale la pena di pensare, in quanto non si dispone di una discreta incarnazione del loro popolare gestito lingue, non che expressivness e potenza.Tutti che da più di 20 anni, che è notevole, e ancora di bootstrap tramite C/C++..Patrimonio di bontà (ma io non sto difendendo 'dark age' C codice c1982-2000, solo l'idea, si può abusi nulla ).