Tarefa de rastreamento (construção de um gráfico de função) - página 5

 
jartmailru:
Análise de código estático... A execução não é necessária.

Eu estava pensando em outra opção - analisar o texto, por assim dizer, analisando o MQL e criando uma estrutura de programa.
Mas eu nem sei por onde começar.

 
tara:

Por que não, se você quiser.

Escolher o meio errado de implementação indica falta de profissionalismo.
 
MetaDriver:

Não é óbvio que este problema é insolúvel? Desta forma, poderíamos eliminar os pares de colchetes aritméticos () [] e operadores {}, e substituí-los por um único par de abertura. Isso é muito fraco?

;)

Por que.

Afinal, há muitas operações unárias também.


jartmailru:
Escolher o meio errado de implementação indica falta de profissionalismo.

Que diferença faz aquilo em que você programa? O que importa em qualquer negócio é a matriz de soluções.
Tudo o resto é irrelevante.
 
jartmailru:
Análise de código estático... A execução não é necessária.
O código é dividido em funções (blocos) e depois é analisado quem chama quem.

Eu tenho a mesma idéia em mente. Somente todo o programa teria de ser minuciosamente analisado para separar as montanhas das borbulhas.

E parece que o personagem principal não precisa disso, se estou adivinhando corretamente, ele precisa imprimir as chamadas sobre o fato. Como se as condições da chamada tivessem ocorrido.

 
sergeev:

Eu estava pensando em outra opção - analisar o texto, por assim dizer, analisando o MQL e criando uma estrutura de programa.
Mas eu nem sei por onde começar com sua implementação.

É elementar.
O que é uma função?
.
[ espaço de palavras / pode não ser ] palavra função nome colchete "(", algo ali, fechamento de colchete ")"".
abre-caracóis {
.
algum código
aparelho encaracolado {, }
.
fechamento encaracolado }
.
A primeira parte do trabalho é feita.
 
sergeev:

:))

a tarefa (se você ler o primeiro post) é adicionar apenas uma função de serviço a cada função do código fonte - logo após "{".

Mas de tal forma para obter todas as passagens do código fonte e construir uma árvore de chamadas.

Neste caso, nem os parâmetros de entrada das funções da fonte, nem seus resultados ou código interno são alterados de forma alguma



Não se trata de traços puros. Trata-se apenas da construção de um gráfico de funções.

Aqui está um trecho do tronco:

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:

Por que.

Afinal de contas, não há poucas operações unárias.

Bem, esta operação claramente não é unária. O "estado de aninhamento" na análise de texto estático é unário. No rastreamento dinâmico é binário. Há um INPUT e um OUTPUT.

Não existe?

 
MetaDriver:

Eu tenho a mesma idéia em mente. Somente todo o programa teria de ser minuciosamente analisado para separar as montanhas das borbulhas.

E me parece que não é isso que o iniciante precisa, se eu intuí corretamente ele precisa imprimir as chamadas sobre o fato. Se as condições da chamada forem atendidas.

Ao analisar, as chamadas propriamente ditas serão detectadas por eles mesmos. Quem está com quem e de onde...

Portanto, esta é a única idéia de solução completa até agora.

 
Não há "análise" completa, assim como "montanhas" e "espinhas"...
.
A propósito... Vou acrescentar:
.
- inicialmente o texto do programa é analisado por um "lexer".
O lexer bate o texto do programa em "fichas".
Em nosso caso, os tokens são:
.
- espaço em branco - espaços, abas, extremidades de linha, etc. -
como não escrevemos o formatador, simplesmente ignoramos estas coisas
- parênteses ( / )
- parênteses [ / ]
- parênteses { / }
- operadores + - / *
- wildcards ;,
todo o resto são essencialmente identificadores
(os números também estarão neste grupo - mas nós não nos importamos).
.
O lexing de análise preenche as estruturas do
estrutura { tipoToken, stringToken }
.
Para a análise, usei um anexo do tipo
structure Tocken { typeToken, stringToken, list<Token> list of anested tokens }
Mas aqui você pode pensar em uma maneira mais simples.
.
E depois faça o agrupamento que mencionei acima - trivial.
.
Na verdade, a combinação lexer + parser é um clássico do gênero.
Sobre a lex/flex/bison/ant-lr não pode aconselhar (eu nem sei o nome ;-D)-.
Eu escrevi exatamente feito à mão.
 

OK. Obrigado a todos pelo debate.