it-swarm.it

Hai usato uno qualsiasi degli interpreti C++ (non i compilatori)?

Sono curioso di sapere se qualcuno ha usato UnderC, Cint, Cling, Ch, o qualsiasi altro interprete C++ e potrebbe condividere la loro esperienza.

65
Allan Wind

NOTA: ciò che segue è piuttosto specifico CINT, ma dato che è probabilmente l'interprete C++ largamente usato può essere valido per tutti.

Come studente laureato in fisica delle particelle che ha ampiamente utilizzato CINT, dovrei avvisarti. Mentre funziona ","/ è in fase di eliminazione graduale , e chi spende più di un anno in fisica delle particelle in genere impara ad evitarlo per diversi motivi: 

  1. A causa delle sue radici come interprete C, non riesce a interpretare alcuni dei componenti più critici del C++. I modelli, ad esempio, non sempre funzionano, quindi ti scoraggerebbe dall'usare cose che rendono C++ così flessibile e utilizzabile. 

  2. È più lento (almeno di un fattore 5) rispetto al C++ minimamente ottimizzato. 

  3. I messaggi di debug sono molto più criptici di quelli prodotti da g ++. 

  4. Lo scoping è incoerente con il C++ compilato: è abbastanza comune vedere il codice del modulo 

    if (energy > 30) { 
        float correction = 2.4;
    }
    else {
        float correction = 6.3;
    }
    
    somevalue += correction; 
    

    mentre qualsiasi compilatore C++ funzionante si lamenterebbe che correcton è andato fuori campo, CINT lo consente. Il risultato è che il codice CINT non è realmente C++, solo qualcosa che sembra. 

In breve, CINT non ha nessuno dei vantaggi del C++ e tutti gli svantaggi più alcuni. 

Il fatto che CINT sia ancora usato è probabilmente un incidente storico a causa della sua inclusione nel framework ROOT. Quando è stato scritto (20 anni fa), c'era un reale bisogno di un linguaggio interpretato per il disegno/adattamento interattivo. Ora ci sono molti pacchetti che riempiono quel ruolo, molti dei quali hanno centinaia di sviluppatori attivi. 

Nessuno di questi è scritto in C++. Perché? Molto semplicemente, C++ non è pensato per essere interpretato. La tipizzazione statica, ad esempio, ti consente di ottenere grandi guadagni nell'ottimizzazione durante la compilazione, ma serve principalmente a ingombrare e forzare eccessivamente il codice se al computer è consentito vederlo solo in fase di runtime. Se hai il lusso di essere in grado di usare un linguaggio interpretato, impara Python o Ruby, il tempo che impieghi per imparare sarà inferiore a quello che perdi inciampando su CINT, anche se conosci già il C++. 

Nella mia esperienza, i ricercatori più anziani che lavorano con ROOT (il pacchetto che devi installare per eseguire CINT) finiscono per compilare le librerie ROOT in normali eseguibili C++ per evitare CINT. Quelli della generazione più giovane seguono questo principio o usano Python per lo scripting. 

Per inciso, ROOT (e quindi CINT) impiega circa mezz'ora per compilare su un computer abbastanza moderno, e occasionalmente fallirà con le versioni più recenti di gcc. È un pacchetto che ha avuto uno scopo importante molti anni fa, ma ora mostra chiaramente la sua età. Esaminando il codice sorgente, troverai centinaia di cast in stile c deprecati, enormi buchi nella sicurezza del tipo e un uso massiccio delle variabili globali. 

Se hai intenzione di scrivere in C++, scrivi C++ così come deve essere scritto. Se devi assolutamente avere un interprete C++, CINT è probabilmente una buona scommessa. 

29
Shep

C'è cling Cern's project dell'interprete C++ basato su clang - è new approach basato su 20 anni di esperienza in ROOT cint ed è abbastanza stabile e raccomandato dai ragazzi del Cern.

Ecco Nice Google Talk: Introducing cling, un interprete C++ basato su clang/LLVM .

23

cint è il processore di comandi per il pacchetto di analisi della fisica delle particelle ROOT . Lo uso regolarmente e funziona molto bene per me.

È abbastanza completo e va d'accordo con il codice compilato (puoi caricare i moduli compilati per l'uso nell'interprete ...)

late edit :: Copiato da un duplicato successivo perché il poster su quelle domande non sembra voler postare qui: igcc . Mai provato personalmente, ma la pagina web sembra promettente.

19
dmckee

Ho (circa un anno fa) giocato con Ch e l'ho trovato abbastanza buono.

4
Alan

Molto tempo fa, ho usato un interprete C++ chiamato CodeCenter. Era piuttosto bello, anche se non poteva gestire cose come bitfield o mania del puntatore. Le due cose interessanti erano che si poteva osservare quando le variabili cambiavano e che si poteva valutare il codice C/C++ al volo durante il debug. In questi giorni, penso che un debugger come GDB sia fondamentalmente altrettanto valido.

2
jfm3

Anche molto tempo fa ho usato una chiamata di prodotto Instant C ma non so che sia mai andata oltre

2
user11269

Esiste un programma chiamato c-repl che funziona compilando ripetutamente il codice in librerie condivise usando GCC, quindi caricando gli oggetti risultanti. Sembra che si stia evolvendo rapidamente, considerando che la versione nel repository di Ubuntu è scritta in Ruby (senza contare GCC, ovviamente), mentre l'ultima versione di git è in Haskell. :)

0

Ho cercato di usare ch un po 'indietro per vedere se potevo usarlo per le DLL di test black box per le quali sono responsabile. Sfortunatamente, non sono riuscito a capire come caricarlo ed eseguire funzioni dalle DLL. Poi di nuovo, non ero così motivato e potrebbe esserci un modo. 

0
Jon Trauntvein