Tarea de trazado (construcción de un gráfico de funciones) - página 5

 
jartmailru:
Análisis de código estático... La ejecución no es necesaria.

Estaba pensando en otra opción: analizar el texto, es decir, analizar el MQL y crear una estructura de programa.
Pero no sé ni por dónde empezar.

 
tara:

Por qué no, si quieres.

La elección de un medio de aplicación erróneo indica falta de profesionalidad.
 
MetaDriver:

¿No es evidente que este problema no tiene solución? De esta manera podríamos eliminar los pares de corchetes aritméticos () [] y de operador {}, y sustituirlos por un único corchete de apertura. ¿Es demasiado débil?

;)

Por qué.

Al fin y al cabo, también hay muchas operaciones unarias.


jartmailru:
La elección de un medio de aplicación incorrecto indica falta de profesionalidad.

¿Qué más da lo que se programe? Lo que importa en cualquier negocio es la matriz de soluciones.
Todo lo demás es irrelevante.
 
jartmailru:
Análisis de código estático... La ejecución no es necesaria.
El código se divide en funciones (bloques) y luego se analiza quién llama a quién.

Tengo la misma idea en mente. Sólo que habría que analizar a fondo todo el programa para separar las montañas de los granos...

Y parece que el protagonista no lo necesita, si no me equivoco, necesita imprimir las llamadas en el hecho. Bueno, como si las condiciones de la llamada tuvieran lugar.

 
sergeev:

Estaba pensando en otra opción: analizar el texto, es decir, analizar el MQL y crear una estructura de programa.
Pero no sé ni por dónde empezar con su aplicación.

Es elemental.
¿Qué es una función?
.
[espacio de la palabra / podría no serlo] nombre de la función de la palabra paréntesis "(", algo allí, cierre de paréntesis ")"
abridores rizados {
.
algún código
llaves {, }
.
cierre rizado }
.
La primera parte del trabajo está hecha.
 
sergeev:

:))

la tarea (si lees el primer post) es añadir sólo una función de servicio a cada función del código fuente - justo después de "{".

Pero de tal manera de obtener todos los pasajes de código fuente y construir un árbol de llamadas.

En este caso, no se modifican los parámetros de entrada de las funciones fuente, ni sus resultados, ni el código que contienen



No se trata de un rastro puro. Sólo se trata de construir la gráfica de una función.

Aquí hay un fragmento 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:

Por qué.

Al fin y al cabo, no son pocas las operaciones unarias.

Bueno, esta operación claramente no es unaria. El "estado de anidación" en el análisis estático de textos es unario. En el rastreo dinámico es binario. Hay una ENTRADA y una SALIDA.

¿No es así?

 
MetaDriver:

Tengo la misma idea en mente. Sólo que habría que analizar a fondo todo el programa para separar las montañas de los granos...

Y me parece que eso no es lo que necesita el titular, si he intuido bien necesita imprimir las llamadas en el hecho. Si se cumplen las condiciones de la convocatoria.

Al analizarlo, las llamadas reales se detectarán por sí mismas. Quién está con quién y de dónde...

por lo que esta es la única idea de solución completa hasta el momento.

 
No hay un análisis "minucioso" así como "montañas" y "granos"...
.
Por cierto... Yo añadiré:
.
- Inicialmente, el texto del programa es analizado por un "lexer".
El lexer bate el texto del programa en "tokens".
En nuestro caso, las fichas son:
.
- espacios en blanco: espacios, tabulaciones, finales de línea, etc. -
como no escribimos el formateador, simplemente ignoramos estas cosas
- paréntesis ( / )
- paréntesis [ / ]
- paréntesis { / }
- operadores + - / *
- comodines ;,
el resto son esencialmente identificadores
(los números también estarán en este grupo - pero no nos importa).
.
Al analizar el léxico, las estructuras del tipo
struct { typeToken, stringToken }
.
Para el análisis sintáctico, he utilizado un archivo adjunto del tipo
struct Tocken { typeToken, stringToken, list<Token> lista de tokens anidados }
Pero aquí se puede pensar en una forma más sencilla.
.
Y luego hacer la agrupación que he mencionado anteriormente - trivial.
.
En realidad la combinación de lexer + parser es un clásico del género.
Sobre lex/flex/bison/ant-lr no puedo aconsejar (ni siquiera sé el nombre ;-D)-.
Escribí exactamente a mano.
 

Bien, gracias a todos por el debate.