Errores, fallos, preguntas - página 2749

 
Roman:

En la página anterior fxsaber dio las medidas.
Ya he explicado por qué es así.
Asigne siempre memoria, de forma estática o dinámica.

¿Qué tipo de medidas? Si te refieres a la tabla grande, entonces sólo se ve la parte izquierda en la pantalla, el resto está cortado, así que no sé qué hay.

Pero a juzgar por el código, si esta macro se compara

GetCurrentTick2(Tick, !i)

Sólo tengo una llamada a la función por cada 100 iteraciones. Y la primera macro tiene una llamada en cada iteración. Así que no tiene sentido.

 
Alexey Navoykov:

Si te refieres a la tabla grande, sólo se ve la parte izquierda en la pantalla, el resto está cortado, así que no sé qué hay.

Pero a juzgar por el código, si esta macro se compara

Y en la primera macro, sólo hay una llamada a la función por cada 100 iteraciones. Por lo tanto, esto no tiene sentido.

El compilador no es omnipotente, a veces hay que participar y ayudarle con el código correcto ))

 
Sergey Dzyublik:
Error en el depurador ME (build 2370) - StepInto (F11) y los puntos de interrupción establecidos manualmente no funcionan.
El problema es que si la acción StepOver (F10) se aplica a una llamada de función al menos una vez, no hay forma de depurar esta función posteriormente.

Pasos de repetición:
1) Ejecutar el código en modo de depuración;
2) Después de que se dispare un punto de ruptura, ejecutar StepOver (F10) dos veces;

Todo - ahora no hay manera de "entrar" en la funciónIncrementar, todos los puntos de ruptura establecidos manualmente no se disparan, y en lugar de la operación StepInto (F11), se ejecuta StepOver (F10).


Gracias por la publicación.

Corregido por

 
Roman:

El compilador no es omnipotente, a veces hay que intervenir ))

¿Qué quieres decir? Me aseguraste que tu construcción es más rápida, pero no lo es. Sólo es 100 veces menos probable que sea llamada en ese código.
 
Alexey Navoykov:

En la primera macro, sólo hay una llamada a la función por cada 100 iteraciones, así que esto no tiene sentido.

La prueba, si no es para escoger la precisión, que no necesitamos aquí, es más o menos normal.
Comparado con: llamar 100 veces a SymbolInfoTick VS llamar 1 vez a SymbolInfoTick y devolver 99 veces la caché "manual".
Muestra cómo no es rentable utilizar la función estándar SymbolInfoTick para el símbolo actual cuando la función será llamada más de una vez en una sola pasada.
Como posible solución al problema, los desarrolladores sugieren introducir una variable predefinida:

const MqlTick _Tick; // Текущий _Symbol-тик.



Es quefxsaber ha desparramado todo por los posts sin explicar nada de nada, es una barbaridad.

 
Alexey Navoykov:

En la primera macro, sólo hay una llamada a la función por cada 100 iteraciones, así que esto no tiene sentido.

Su ejemplo es un uso específico de los datos de oferta y demanda en diferentes partes del programa MQL, cuanto más a menudo se accede a SymbolInfoTick(), menor es el rendimiento de la prueba

He encontrado algunos problemas de rendimiento con TimeCurrent(), lo he probado de diferentes maneras y luego lo he descartado,

Rara vez uso la visibilidad de las variables globales, pero para que todo "vuele" en el probador, lo escribo así:

MqlTick Tick = {0};
#define  Ask Tick.ask
#define  Bid Tick.bid
#define  TimeCurrent_ Tick.time
//+------------------------------------------------------------------+
void OnTick()
{
   SymbolInfoTick(_Symbol,Tick);
  ....
}
 
Alexey Navoykov:
¿Qué quieres decir? Me aseguraste que tu diseño es más rápido, y no es más rápido, sólo es 100 veces menos probable que sea llamado en ese código.

Este no es mi diseño, y según entendí de ese ejemplo, las macros fueron llamadas una por una para la prueba.
Y el informe de pases se muestra junto, aunque está recortado, se puede ver el tiempo de ejecución.

 
Sergey Dzyublik:

La prueba, si no te importa la precisión, que no necesitas, es más o menos normal.
Comparado con llamar 100 veces a SymbolInfoTick VS llamar una vez a SymbolInfoTick y devolver 99 veces la caché "manual".

Sí, entiendo lo del caché. Es que Roman aquí estaba frotando algo sobre la asignación de memoria... Parece que tenías razón sobre el troll )

 
Alexey Navoykov:

Sé lo del caché. Es que aquí Román estaba restregando algo sobre la asignación de memoria... Parece que tenías razón con lo del troll )

¿Dónde crees que se asigna el caché? Tontos.

 
Sergey Dzyublik:

La prueba, si no te importa la precisión, que no necesitas, es más o menos normal.
Comparación: llamar 100 veces a SymbolInfoTick VS llamar 1 vez a SymbolInfoTick y devolver 99 veces el caché "manual".
Muestra cómo no es rentable utilizar la función estándar SymbolInfoTick para el símbolo actual cuando la función será llamada más de una vez en una sola pasada.
Como posible solución al problema, se anima a los desarrolladores a introducir una variable predefinida:

Entiendes mi punto de vista al 100%.

La razón es quefxsaber había difundido todo en sus posts sin explicarlo y es difícil de entender.

Lo siento, no lo he formulado bien.