Trace task (costruire il grafico di una funzione) - pagina 5

Nuovo commento
 
jartmailru:
Analisi statica del codice... L'esecuzione non è richiesta.

Stavo pensando a un'altra opzione - l'analisi del testo. per dire, analizzare MQL e creare una struttura di programma.
Ma non so nemmeno da dove cominciare.

 
tara:

Perché no, se vuoi.

Scegliere i mezzi di attuazione sbagliati indica mancanza di professionalità.
 
MetaDriver:

Non è ovvio che questo problema è irrisolvibile? In questo modo potremmo eliminare le coppie di parentesi aritmetiche () [] e operatore {}, e sostituirle con una sola parentesi di apertura. È troppo debole?

;)

Perché.

Dopo tutto, ci sono anche molte operazioni unarie.


jartmailru:
Scegliere i mezzi di attuazione sbagliati indica mancanza di professionalità.

Che differenza fa in cosa si programma? Ciò che conta in ogni business è la matrice della soluzione.
Tutto il resto è irrilevante.
 
jartmailru:
Analisi statica del codice... L'esecuzione non è richiesta.
Il codice viene spezzato in funzioni (blocchi) e poi si analizza chi chiama chi.

Ho la stessa idea in mente. Solo che l'intero programma dovrebbe essere analizzato a fondo per separare le montagne dai brufoli...

E sembra che il protagonista non ne abbia bisogno, se ho indovinato bene, ha bisogno di stampare le chiamate sul fatto. Beh, come se le condizioni della chiamata avessero avuto luogo.

 
sergeev:

Stavo pensando ad un'altra opzione - analizzare il testo. per dire, analizzare MQL e creare una struttura di programma.
Ma non so nemmeno da dove cominciare con la sua implementazione.

È elementare.
Cos'è una funzione?
.
[ parola spazio / potrebbe non essere ] parola nome della funzione parentesi "(", qualcosa lì, parentesi di chiusura ")"
apripista a ricciolo {
.
un po' di codice
parentesi graffe {, }
.
curly closing }
.
La prima parte del lavoro è fatta.
 
sergeev:

:))

il compito (se avete letto il primo post) è di aggiungere solo una funzione di servizio ad ogni funzione del codice sorgente - subito dopo "{".

Ma in modo tale da ottenere tutti i passaggi di codice sorgente e costruire un albero delle chiamate.

In questo caso né i parametri di input delle funzioni sorgente, né i loro risultati o il codice all'interno sono cambiati in alcun modo



Non si tratta di una traccia pura. Si tratta solo di costruire il grafico di una funzione.

Ecco un frammento del registro: 

01:45:18 CTA0 USDCHF,H1: loaded successfully
01:45:18 CTA0 USDCHF,H1 inputs: BarsBeforeActivate=1; BarsBeforeConfirm=0; TraceIsAllowed=true; IsStaticMode=false; ClearAtFinish=true; ExcludeFirstBar=false; ExcludeLastBar=true; RasingLinesColor=(0,128,128); ReducingLinesColor=(255,0,255); 
01:45:18 CTA0 USDCHF,H1: Init
01:45:18 CTA0 USDCHF,H1: Init=>NewBar(DeadLine)
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>InitType
01:45:18 CTA0 USDCHF,H1: Init=>DeleteGroup(Init)
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>ClearGroup
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>ClearGroup=>ClearTrend
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>ClearGroup=>ClearTrend=>ClearTrace
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>ClearGroup(Empty)
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>ClearGroup(Empty)=>ClearTrend
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>ClearGroup(Empty)=>ClearTrend=>ClearTrace
01:45:18 CTA0 USDCHF,H1: Init=>LoadGroup(ClearScreen)=>SaveGroup(Empty)
01:45:18 CTA0 USDCHF,H1: Init=>PaintGroup(ClearScreen)
 
sergeev:

Perché.

Dopo tutto, non ci sono poche operazioni unarie.

Bene, questa operazione non è chiaramente unaria. Lo "stato di annidamento" nell'analisi statica del testo è unario. Nel tracciamento dinamico è binario. C'è un INPUT e un OUTPUT.

Non c'è?

 
MetaDriver:

Ho la stessa idea in mente. Solo che l'intero programma dovrebbe essere analizzato a fondo per separare le montagne dai brufoli...

E mi sembra che non è quello di cui ha bisogno il titolare, se ho intuito bene ha bisogno di stampare le chiamate sul fatto. Se le condizioni della chiamata sono soddisfatte.

Durante il parsing, le chiamate effettive saranno rilevate da sole. Chi è con chi e da dove...

quindi questa è l'unica idea di soluzione completa finora.

 
Non c'è un parsing "approfondito" così come "montagne" e "brufoli"...
.
A proposito... Aggiungo:
.
- Inizialmente il testo del programma viene analizzato da un "lexer".
Il lexer batte il testo del programma in "token".
Nel nostro caso, i gettoni sono:
.
- spazi bianchi - spazi, tabulazioni, fine riga, ecc. -
dato che non scriviamo il formattatore, ignoriamo questa roba
- parentesi ( / )
- parentesi [ / ]
- parentesi { / }
- operatori + - / *
- caratteri jolly ;,
tutto il resto sono essenzialmente identificatori
(i numeri saranno anche in questo gruppo - ma non ci interessa).
.
Il lexing di parsing riempie le strutture dell'elemento
struct { typeToken, stringToken }
.
Per il parsing, ho usato un allegato del tipo
struct Tocken { typeToken, stringToken, list<Token> lista di token annidati }
Ma qui si può pensare a un modo più semplice.
.
E poi fare il raggruppamento di cui ho parlato sopra - banale.
.
In realtà la combinazione lexer + parser è un classico del genere.
Su lex/flex/bison/ant-lr non posso consigliare (non so nemmeno il nome ;-D)-.
Ho scritto esattamente a mano.
 

Ok, grazie a tutti per il dibattito.

123456789
Nuovo commento
Motivazione: