dead

[legacy]

• 

dead

[TheKaneB]

• 

eheheh molto meglio di prima direi

[TheKaneB]

• 

la cosa buona del C++ è una discreta quantità di algoritmi e strutture dati presenti in STL, che sono molto comodi.

Se ti serve qualche algoritmo non incluso, usa Boost, è una "template library", in pratica sono pezzi di codice da includere soltanto (non c'è quasi nulla da linkare) perchè quasi tutto implementato come template sugli header files. Le uniche parti linkabili di Boost sono librerie per trattare l'XML o per integrare Python, mi pare, ma il grosso è costituito da semplici header.

La cosa comoda è che Boost è che compila su qualsiasi compiler moderno e funziona su qualsiasi architettura senza richiedere supporto runtime.

[Z80Fan]

• 

Bellino, lo ho provato e funziona perfettamente.

Non so cosa ci sia da "ritoccare", diciamo che si vede che è stato scritto da uno con un forte background di C (ciò non vuol dire che sia male). Probabilmente si può trovare una soluzione più object oriented...

Prova a descrivere l'architettura di alto livello, che così vediamo come cambiare.

[cdimauro]

• 

Intanto la sintassi è carina, visto che prende molto dal Pascal anziché dal C, e ciò è cosa buona e giusta.

Se vuoi divertirti a scrivere parser più complicati senza impazzire, ti consiglio di utilizzare ANTLR.

Ultima cosa: non mi piace l' & per indicare l'and logico nelle condizioni, e il ! per la negazione logica. Io amo le keyword: and/or/xor/not sono di gran lunga più autoesplicative e leggibili.

Comunque avrei anche usato il := per l'assegnazione e l' = per l'uguaglianza, per ragioni simili.

[cdimauro]

• 

Però se passi ad ANTLR hai il vantaggio di utilizzare lo stesso linguaggio (peraltro molto semplice, se hai avuto modo di dargli un'occhiata) per definire lexer, parser, e l'attraversatore degli AST che eventualmente generi col parser. Inoltre man mano puoi complicare / estendere il tuo linguaggio senza troppe difficoltà.

Altra cosa, c'è a disposizione ANTLRWork che è un IDE eccezionale per definire la tua sintassi, che ti fa vedere in tempo reale il grafo generato per il tuo linguaggio, e se ci sono errori eventualmente.

Dai un'occhiata a entrambi: vedrai che ne vale veramente la pena.

[Z80Fan]

• 

Io sì, da premettere che piace anche a me, ma è da riscrivere in vari punti, soprattutto la parte delle expression.

In realtà non ho analizzato tutto il codice a fondo, lo ho solo guardato sommariamente; se si vuole "ritoccare" per essere più in stile C++ secondo me bisogna quasi riscriverlo da capo.

Per l'OOP pensavo a qualcosa tipo classi diverse che parsano elementi diversi: per ogni linea di codice, ci sarà una classe tipo ParseLine, che sa come individuare le keyword "principali" di quella linea, e poi richiama altre classi che sono specializzate nel parsing di quello che serve.

Ad esempio, in una linea come "if a=b", il ParseLine vedrà l' "if", cercherà in una mappa la classe appropriata (ParseIf), e la chiamerà; quest'ultima sa che dopo un if serve un'espressione, perciò chiamerà qualcosa di adeguato (ParseExpression). Eventualmente queste classi (anche con nomi più significativi se serve) potranno essere usate per la costruzione dell'AST, ed eventualmente contenere funzioni anche per l'esecuzione.

Non so come fa adesso, ma io lo progetterei per prima eseguire il parse di tutto il sorgente e costruire l'AST, e poi passare all'esecuzione, così si ha il vantaggio di trovare eventuali problemi di sintassi subito e non durante l'esecuzione e in più si può salvare l'AST in un file "compilato" per rendere veloci le successive esecuzioni.

Come dicevo in privato a legacy, se facciamo le cose bene arriveremo a un punto dove "il sorgente si parsa da solo".



Se posso spammare un pochino, ho scritto un grande post sul thread del mio hobby kernel, se qualcuno ha qualche esperienza (o anche solo curiosità) sui sistemi di message passing, IPC e RPC prego di dargli un'occhiata.

[Z80Fan]

• 

poi ci sarebbe da pensare alle function call, e qui SoS =P

Non credo sia così tragico: avendo l'AST già pronto, ogni volta che c'è una chiamata a funzione basta tenersi un puntatore del punto dove si era arrivati prima e passare all'esecuzione della funzione.

Forse si riesce a sfruttare la stessa chiamata a funzione del C++ per aiutarsi in questo: se abbiamo una funzione generale del tipo parseCode(AST partenza, stack parametri), se nel mezzo dell'esecuzione troviamo una chiamata a funzione, nel codice dell'interprete facciamo parseCode(AST funzione, stack con parametri per la funzione) e dovrebbe funzionare senza problemi.

[cdimauro]

• 

Dovrebbe essere sufficiente allocare uno stack frame per tutte le esigenze di spazio della funzione da invocare, e il gioco è fatto. Ovviamente al ritorno si dealloca. Ed eventualmente si può realizzare un pool di frame dai quali attingere velocemente, anziché allocare deallocare continuamente.

[cdimauro]

• 

Parla più fort, che non ti sento.