Newsgroup: it.comp.lang.c++
Titolo: Linguaggi di script per il C++

Salve a tutti,
avrei bisogno di utilizzare un linguaggio di script che si
interfacci ad applicazioni C++ e con le quali possa
scambiarsi dati. Io ho provato a dare un'occhiata a
python ma l'interfacciamento con il c++ mi sembra un
po' macchinoso. Qualcuno di voi ha gia' affrontato
il problema e sa darmi qualche consiglio?
grazie a tutti

scambiarsi dati.
Perl.
Per esempio:
.....
use Ole;
$xml = CreateObject OLE 'appxml.appxmlconv';
$version = $xml->Version;
print "\n$version\n\n";
print "Converting text : $ARGV[0]\n";
print "Using queue     : $ARGV[1]\n";
$xml->ConvertAuto($ARGV[0], $ARGV[1]);
.....
Dove l'activeX è stato scritto in VC++ (ovviamente ti riferivi a
windows...)
Easy, no?
Luc.

Luc.
In realta' quello che mi serve e' un linguaggio di script i cui
programmi vengano eseguiti invocando una particolare funzione, es:
	ScriptEngine->Execute(commands);
con lo script contenuto in commands (ad es. una stringa o un array di
stringhe). Lo script, durante la sua esecuzione comunica al programma
C++ invocando a sua volta delle funzioni, es:
	ComandoScript1
	ComandoScript2
	ChiamaFunzioneC++
	ComandoScript3
	Fine.
 

	ScriptEngine->Execute(commands);
...
Io ho sempre scritto i miei interpreti/compilatori da solo ma ho
sentito dire che TCL puo' essere impiegato facilmente nel modo
che descrivi. Io non conosco pero' TCL (come scripting uso PERL) e
quindi ti posso solo consigliare di cercare riferimenti o
informazioni su internet (sperando che non mi abbiano detto una
bufala).
Scriversi un interprete (o meglio uno pseudo-compilatore) da soli
non e' complicatissimo ma non e' nemmeno banale se il linguaggio
di scripting deve essere sofisticato (espressioni complesse,
funzioni definite dall'utente, tipi definiti dall'utente,
linguaggio script object oriented, overloading di operatori,
gestione exception).
D'altra parte un linguaggio di scripring simile al vecchio
BASIC (al limite con label alfanumeriche) dovrebbe richiedere
uno sforzo minimo per essere implementato e forse nel tuo
contesto sarebbe anche preferibile per l'utente finale che deve
scrivere gli script. Se poi ti bastasse qualcosa come il
FORTH allora probabilmente basterebbero veramente poche
linee di C++ per implementare l'interprete (anche se un utente
che dovesse usarlo probabilmente cercherebbe di assoldare un
killer per far uccidere chi ha avuto l'idea).
Se il tuo ambiente e' poi esclusivamente MS e non ti interessa
il fatto di precludere la portabilita' potresti guardare i
concetti di ActiveScripting MS (anche su questo parlo per
sentito dire... non sono cose che ho mai usato davvero).
HTH
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

 wrote in message
news:3a55dc54...@news.cis.dfn.de...
[ringrazio Lello Mele di avermi segnalato questo thread,
visto che attualmente non seguo questo gruppo mentre lo
scripting e` fra i miei principali interessi!]

Interfacciare linguaggi di scripting _al C_ non e` banale
(TCL e` quello che, tutto sommato, fa sudare di meno; come
linguaggio ha i suoi dimolti difetti, ma interfacciarlo a C
e` piu` semplice che per qualsiasi altro linguaggio di
scripting).
L'interfaccia _al C++_ invece e`, fortunatamente, molto ma
molto meno problematica.  Per Python, in particolare, ci sono
due ottime scelte per questo compito: il package CXX del
LLNL (
http://cxx.sourceforge.net
), e il package Boost Python
Library (BPL), parte dell'_eccellente_ progetto open-source
chiamato, appunto, 'Boost' (
http://www.boost.org
).
Personalmente, avendo provato entrambi (ed altri package
ancora per gli stessi compiti), preferisco Boost: e` piu`
nuovo, quindi anche meno maturo, tuttavia la sua stabilita`
e completezza sono gia` ottime e gli autori sono attivi,
cortesi, responsivi.  BPL (come, piu` in generale, l'intero
progetto Boost) sfrutta in modo ottimo le potenzialita`
(davvero incredibili...) dei template del C++.
Secondo me, il fatto che BPL sia (giustappunto) parte di Boost
e` un altro importante fattore favorevole, poiche` Boost si
sposa in modo cosi` splendido con le funzionalita` fornite
dalle librerie standard C++ (particolarmente gli insiemi di
template spesso, benche` non del tutto correttamente, detti
'STL') o anche (per chi e` avventuroso ed ama usare nel suo
software pacchetti avanzati e 'di ricerca') con la STL vera
e propria (Boost stesso lo trovo molto solido, e, come per
la libreria standard del C++, non avrei [anzi, no ho] alcun
dubbio a raccomandarne l'uso in software "di produzione").
Boost richiede un compilatore C++ decentemente moderno ed
allineato con lo standard; per intenderci, gcc o Microsoft
Visual C++ 6 vanno gia` bene (e cosi` pure, immagino, ogni
altro compilatore C++ attualmente in vendita!), mentre non
e` detto che le cose vadano lisce se il proprio obbiettivo
e` di usare un qualche compilatore proprietario acquistato
un 5 o 6 anni fa (obbiettivo che comunque sconsiglierei).
La "enfasi" di Boost e` ('naturalmente', direi) relativa a
come il software C++ possa esporre le proprie funzionalita`
all'interprete Python che incorpora (potremmo dire, alle
"chiamate da Python a C++").
L'"altro verso" della comunicazione, infatti, non presenta
comunque particolari problemi -- dopo una semplice chiamata
"Py_Initialize();" in fase di partenza, e` infatti assai
facile chiedere all'interprete Python di compilare ed eseguire
sorgenti Python passatigli come stringhe (PyRun_SimpleString,
ad esempio) o file (con PyRun_SimpleFile, ad esempio), o,
naturalmente, anche eseguire altre operazioni piu` dettagliate
e avanzate (ottenere oggetti-modulo con PyImport_ImportModule;
ottere oggetti, conoscendone il nome ed il modulo di residenza,
con PyObject_GetAttrString; chiamare metodi [o funzioni] con
PyObject_CallMethod, e via elencando).
Dal punto di vista delle chiamate da C++ a Python, in pratica,
l'unico 'valore aggiunto' che fa veramente comodo rispetto alle
"nude C/API" del Python (e BPL, naturalmente, lo fornisce) e`
uno 'smart pointer' che rivesta i nudi puntatori PyObject*
occupandosi della gestione dei relativi reference-count.
Il BPL aiuta invece moltissimo ad esporre nel modo piu`
semplice e produttivo le funzionalita` del proprio codice
C++ al codice Python che si vuole chiamare, creando ed
esponendo moduli e classi (nel senso Python del termine).
I template del BPL si occupano della infrastruttura e inoltre
danno il valore aggiunto di potere, in modo elementare, esporre
le proprie classi C++ (o loro sottoinsiemi, aggregazioni, ...)
al codice Python *come classi Python a tutti gli effetti*, cosi`
permettendo l'eredita` (anche multipla), l'override di funzioni
virtuali, la definizione di metodi speciali (usati da Python per
gli operatori: ad esempio, il metodo __add__ in una classe Python
equivale all'operator+() del C++, e viene implicitamente usato,
se presente, in espressioni del tipo "a+b"), e cosi` via.
Come se non bastasse, le classi-Python esposte da BPL sfruttano
il concetto avanzato di "metaclasse" Python per esporre alcune
potenzialita` particolarmente avanzate, come la possibilita` di
avere automaticamente accessori e mutatori specifici per vari
attributi ("proprieta`") -- ad esempio, se il lato Python usa
    x.pippo = 'ciao'
e x e` un oggetto di una classe (esposta dal BPL, con eredita`
e overriding dal lato Python) che ha un metodo chiamato
__setattr__pippo__, quest'ultimo verra` automaticamente
chiamato per gestire l'"assegnamento" (dal lato C++, BPL non
si appoggia su convenzioni relative ai nomi, bensi` su espliciti
"agganci" di specifici mutatori via def_setter o def_read_write);
similmente, se il lato Python fa qualcosa del tipo
    print x.pippo
possono entrare implicitamente in gioco __getattr__pippo__,
o metodi C++ impostati con def_getter, def_readonly, o anche
naturalmente def_read_write.
Mi e` difficile pensare ad un framework di integrazione fra
2 specifici linguaggi (uno 'di sistema', uno 'di scripting')
meglio progettato o eseguito della Boost Python Library: le
cose semplici sono rese semplici, mentre anche cose molto, ma
MOLTO avanzate, sono perfettamente possibili e tutt'altro che
difficili.  Spostare funzionalita` dal lato Python a quello
C++ e viceversa risulta agevole, il che facilita l'uso di
Python per 'prototipare' checchessia (anche se destinato poi
ad essere implementato in C++ nel codice 'di produzione') e
viceversa facilita la reimplementazione in C++ di eventuali
parti, originalmente sviluppate in Python, che si dovessero
rivelare "colli di bottiglia" computazionali.
Se NON interessa operare "cross-platform" (cioe` con codice che
puo` facilmente migrare fra svariate piattaforme, come Windows,
Linux, altri Unixlike, Mac..., semplicemente ricompilando le
sole parti C++); e, viceversa, si ha la necessita` di interoperare
(su di una sola piattaforma) fra linguaggi molteplici; allora
esistono altre soluzioni.  Ancora immature, purtroppo, quelle
basate su XPCOM (la versione 'portatile' di COM, che Mozilla ha
sviluppato come parte della sua architettura).  Matura, diffusa,
solida, e ottimamente performante, invece, l'architettura COM
vera e propria -- purtroppo, funzionante sulle sole piattaforme
Microsoft.  Se l'integrazione fra C++ e linguaggi (plurale) di
scripting deve avvenire su sole piattaforme Microsoft, COM e`
dunque una possibile (e buona) scelta, specificamente attraverso
l'architettura ActiveScripting (la piu` semplice implementazione
della quale, per l'embedding di script nella propria esistente
applicazione, e` attraverso il Microsoft Script Control).
L'applicazione C++ deve esporre le proprie funzionalita` come
oggetti COM (con interfacce duali), bene implementabili ad es.
con la libreria ATL della Microsoft, inclusa in Microsoft Visual
C++ 6.  Essa istanzia poi uno o piu` componenti ScriptControl,
e, settandone le proprieta` Language, determina quali linguaggi
di scripting essi gestiranno (JScript, implementazione dello
standard ECMA [simil-JavaScript], e VBScript, sottoinsieme di
Visual Basic per lo scripting, sono distribuiti da Microsoft;
molti altri linguaggi di terze parti, come Perl e Python, hanno
anche la possibilita` di giocare a pieno titolo nella squadra
ActiveScripting).
Un tempo (prima che emergessero ambienti come BPL) avrei di
certo consigliato questo approccio se il vincolo alle sole
piattaforme Microsoft non era un problema.  Oggi, pero`, io lo
consiglierei solo se l'uso di molteplici disparati linguaggi di
scripting e` una specifica esigenza dell'applicazione.  Se
basta un linguaggio solo, l'uso di Python e della Boost Python
Library presenta sostanziali vantaggi, soprattutto vantaggi di
semplicita`, ma, in molti casi, anche di prestazioni (ad es.,
l'uso di COM/Automation implica che il passaggio delle stringhe
attraverso l'interfaccia avvenga sempre in termini di Unicode;
se la propria applicazione, internamente, non sfrutta Unicode,
ma e` invece limitata a un character set single-byte, puo` darsi
che le continue conversioni avanti e indietro finiscano per
rappresentare un discreto, evitabile overhead -- usando BPL, si
puo` sfruttare la capacita` di Python di operare altrettanto
bene con insiemi di caratteri single-byte, cosi` come con
Unicode, evitando le inutili conversioni "in puro overhead").
Resto a disposizione per qualsiasi ulteriore aiuto o chiarimento
(prego di postare le richieste sul gruppo _e_ inviarmene anche
copia in e-mail, poiche` in questi giorni non seguo regolarmente
questo newsgroup).
Alex

C++ invocando a sua volta delle funzioni, es:
Da alcune settimane sto cercando anch'io un linguaggio di scripting
per rendere estendibile la mia applicazione.
Ne esistono veramente tanti:
TCL, Python, Perl: sono completi e molto supportati ma anche complessi
e voluminosi.
Potresti orientarti verso alcuni linguaggi lisp-like con interpreti
snelli e facilmente estendibili come QScheme, siod, newlisp tutti
distribuiti con i sorgenti.
Oppure pike, piu' simile al c   (
http://pike.roxen.com
).
Oppure ruby, object oriented (
http://www.ruby-lang.org/en/links.html
),
ne parlano molto bene e dicono che e' facile da estendere con classi
C++.
Uno dei miei preferiti e' LUA (
http://www.tecgraf.puc-rio.br/lua/
)
distribuito con sorgenti ANSI C, sto imparando ad usarlo ed e'
veramente molto semplice e potente anche se non molto OO.
Chiedi pure se vuoi altri links.
	Ciao