2012-01-27 15 views
6

Esistono linguaggi di programmazione interpretati estensibili scritti in standard C o C++ indipendenti dalla piattaforma?Interpreti scritti in standard C o C++

Mi piacerebbe essere in grado di mettere semplicemente tutte le fonti in una directory, compilare le fonti con qualsiasi compilatore C o C++ standard compatibile e produrre un eseguibile che legge e interpreta i file di script nel linguaggio di scripting designato.

Sembra che molti linguaggi di programmazione "scritti in C" spesso incorporino molte funzionalità dipendenti dalla piattaforma in cui si trovano e, di conseguenza, richiedono alcuni programmi di configurazione da eseguire in base al sistema di destinazione (ad esempio Autoconf) che complica gli argomenti e limita la compatibilità multipiattaforma.

Motivo della domanda:

Sono interessato a conoscere il linguaggio di programmazione di progettazione. Ho suonato con alcuni linguaggi di programmazione giocattolo dopo aver seguito le esercitazioni su yacc, lex e llvm. Tuttavia, recentemente mi sono interessato allo studio di un linguaggio di programmazione scritto in C/C++ portatile, in questo modo, posso studiare il programma e il codice su qualsiasi macchina che supporti un compilatore standard C o C++ (forse anche sul mio ipad) e comunque avere un'esperienza ragionevolmente uniforme

Poiché questo è solo per scopi didattici, il linguaggio di scripting non ha bisogno di supportare funzionalità di basso livello come C, né deve avere una GUI come Java (non penso che tu possa scrivere alcun tipo di interfaccia grafica comunque limitato allo standard C/C++) o qualsiasi io complicato. Tuttavia, vorrei che il linguaggio fosse abbastanza completo da essere pratico per scrivere alcuni programmi utili nella lingua (per esempio dovrebbe essere possibile estendere la lingua usando C/C++ in modo da poterlo usare come una shell su tty) .

Grazie.

Edit:

@ AndréCaron Io preferirei che se almeno il nucleo del linguaggio è stata la piattaforma al 100% indipendente. Sarebbe ok se la lingua includesse una grande libreria standard che dipendesse da altre librerie per renderla "più utile", tuttavia, mi piacerebbe essere in grado di spogliare la libreria standard e usare solo il nucleo del linguaggio (possibilmente con un custom librerie scritte a mano) se volessi.

+0

Questa è davvero una domanda migliore per il sito [programmatori] (http://programmers.stackexchange.com). –

+2

Come è fuori tema? Sembra adattarsi saldamente a [argomenti esclusi da Programmers.SE] (http://programmers.stackexchange.com/faq). –

+0

"Incorpora i sorgenti della libreria nel mio albero dei sorgenti" non è in realtà un modo comune per includere le librerie nel progetto al di fuori della piattaforma iOS. Se intendi utilizzare C, dovresti considerare di aggiungere "utilizzando librerie di terze parti" e "gestione degli autotools" ai tuoi obiettivi educativi. – millimoose

risposta

9

Forse embedded Lua?

In realtà lo stesso core Lua è probabilmente migliore. A prima vista, ho pensato che l'uso di eLua di girare su molti sistemi diversi significava che era altamente portatile, ma in realtà ci vuole un core Lua e aggiunge un sacco di driver hardware, che ovviamente non sono così portatili.

Ocaml sarebbe un'altra scelta eccellente. Sostiene "The bytecoded system currently runs on any POSIX-compliant operating system with an ANSI-compliant C compiler" E Caml Light è particolarmente adatto per l'apprendimento. "Il sistema di runtime e l'interprete bytecode sono scritti in standard C, quindi Caml Light è facile da portare su quasi tutte le piattaforme a 32 o 64 bit."

+0

Purtroppo, no. Da http://www.eluaproject.net/doc/master/en_building.html: "** eLua ** ha un sistema di compilazione molto flessibile [...]. Per utilizzarlo, è necessario modificare un singolo file di configurazione (* platform_conf.h *) che si trova nella directory specifica della piattaforma (* src/platform/ /platform_conf.h*). " – ruakh

+4

Beh, non è perfetto - ma non penso che ci sia qualcosa come una piattaforma cross-platform indipendente. Se ci fossero, allora tutte le piattaforme sarebbero coerenti e non ci sarebbero affatto problemi multipiattaforma, giusto? Tutto sarebbe semplicemente indipendente dalla piattaforma. Il valore di Lua è che le modifiche necessarie sono piccole e in un solo file, hanno già fatto il lavoro per rendere la piattaforma _code_ indipendente. La mia comprensione è che stai solo modificando la build, non l'interprete. – Matt

+0

@Matt: Penso che il punto sia che le librerie di runtime C (e C++) dovrebbero astrarre (quasi) tutte le differenze della piattaforma. Ma le API C standard richiedono ancora all'app di utilizzare dati specifici della piattaforma come i nomi di file. –

6

Lua è davvero la soluzione migliore. L'interprete principale di Lua è il più minimalista possibile. La distro include un makefile, ma è praticamente privo di ossa. Esistono persino istruzioni che spiegano quali file sono necessari per creare solo il linguaggio principale, quali sono la libreria standard Lua e quali sono l'interprete della riga di comando.

Il linguaggio di base in sé non tocca API o intestazioni specifiche della piattaforma.La libreria standard lo fa, ma solo nel modo più minimale. E tu non hai per costruire la libreria standard se non ne hai voglia.

Ci sono alcuni #definimenti che è possibile utilizzare per configurare la build, ma questo è principalmente per cose come la costruzione di DLL e simili.

Nota: Lo scopo di autotools e altre utilità di configurazione di compilazione specifici della piattaforma è quello di consentire alle biblioteche di avvolgere in modo efficace roba specifico per la piattaforma all'interno un'interfaccia indipendente dalla piattaforma. Non c'è molto che tu possa fare sulla maggior parte delle piattaforme con librerie standard C o C++ puramente platform-neutral. Non puoi nemmeno accedere agli alberi delle directory e cercare i file, per non parlare di cose davvero utili come aprire una finestra. Per semplici applicazioni stdin/stdout, potrebbe essere sufficiente. Ma per la stragrande maggioranza dei casi, non lo è.

Il mio suggerimento è che ci si abitua a dover configurare una build per una piattaforma specifica. A meno che il tuo dominio non sia applicazioni scientifiche (e in alcuni casi, nemmeno in quel caso), non otterrai molto dalla programmazione agnostica della piattaforma. Dovrai imparare a lavorare con questo tipo di librerie.

Lua è un exlier quando si tratta di librerie. La maggior parte delle librerie non sono elenchi di file che è possibile inserire in una directory e compilare volenti o nolenti. Prima capirai come lavorare con gli strumenti che le librerie usano, meglio sarà.

0

LUA e TCL sono i due linguaggi interpretati più semplici, quindi prendi una copia del codice sorgente per entrambi ed esaminala. Tuttavia, penso che la tua domanda sia più legata al collegamento statico rispetto al collegamento condiviso. Un programma collegato staticamente non ha dipendenze di sistema oltre all'interfaccia del kernel, ma un programma collegato in modo dinamico richiede il set corretto di librerie condivise da installare.

Con un linguaggio come Python è necessario preoccuparsi delle librerie di Python (chiamate moduli) e di tutte le librerie binarie condivise da cui dipende un modulo. Python stesso è solitamente costruito usando librerie condivise, ma it can be built statically. Inoltre, ho creato un binario Python that uses the Linux shared library RUNPATH feature so that all binary dependencies can be bundled with Python nella sua gerarchia di cartelle.

Se la tua domanda riguarda più il collegamento, dai un'occhiata a come è stato sviluppato StaticPython rispetto a Python dinamico standard e agli script di generazione Pybuild utilizzando RUNPATH.

0

Quasi tutti i più recenti linguaggi di scripting sono scritti in C o C++: Perl, bash, csh, PHP, HTML, Javascript, fare, vim, TCL, ecc, ecc

Il fatto che la loro costruzione richiede la configurazione non è una caratteristica dell'interprete tanto quanto è un adattamento per la costruzione su più piattaforme — di solito considerato una buona cosa.

Sono tutti estensibili nel senso che è possibile scrivere funzioni che creano nuove funzionalità.