Errores, fallos, preguntas - página 2754

[A100]

fxsaber:

La cuestión es poder pasar por referencia.

Al igual que con las cadenas, los desarrolladores tienen la oportunidad (si no lo han hecho ya) de pasar todo por referencia sin copiar realmente la variable.

void f()
{
        MqlTick tick;
        SymbolInfoTick( NULL, tick );
        g( tick );
}

inline void SymbolInfoTick( string symbol, MqlTick& tick )
{
      tick = _LastTick; //л енивое программирование: а не будем ничего копировать,
                        //пока _LastTick не изменится
}

Y será una solución no para una estructuraMqlTick en particular, sino para todas las ocasiones

[Ilyas]

A100:

Lo que confirma una vez más que no tiene sentidoutilizar directamente _Digits,_Point , _Period, _LastError, etc. (e incluso _Symbol puede ser sustituido por NULL). De hecho, deben ser declarados como volátiles const

Y usted, por el contrario, propone ampliar este rango

Tienes razón, pero soncasi volátiles, excepto la bandera IsStopped - es 100% volátil, es decir, cualquier lectura de IsStopped es 100% lectura de memoria.
Para otros,casivollatylе significa que el compilador PUEDE almacenar en caché el valor de una variable en un registro en la primera llamada y utilizar el valor almacenado en caché la próxima vez que se acceda a dicha variable, pero sólo dentro de una función o rama de llamadas, si están inlineadas en una función.
Esto es posible (y necesario) porque el cambio de variables predefinidas (excepto IsStopped) no puede ocurrir dentro de un punto de entrada MQL (función OnXXX)

En cuanto al MODIFICADOR DEVARIABLES, digamos que lo utilizan los programadores de const para los programadores.
Como sabemos, se puede cambiar la constante de una variable a través de la conversión, por lo que no se puede confiar en el compilador con el modificador const.
Si el compilador ve que la variable no ha cambiado su valor y está inicializada como una constante, convertirá dicha variable en un valor inmediato (ImmediateValue) incluso sin el modificador const

. Respecto a _LastTick, estamos discutiendo pero...
Se trata de una estructura, no de un simple tipo atómico, y puede cambiarse de repente, en cualquier punto del programa MQL, incluso en el momento de obtener el valor.
Resulta que para abordar esta estructura hay que introducir un sincronizador.

Estamos trabajando constantemente en el rendimiento, en particular, debido a este alto ritmo de lanzamiento de compilaciones.
Planeamos hacer mucho trabajo para acelerar el código MQL

[Igor Makanu]

Ilyas:

En cuanto a _LastTick, estamos discutiendo, pero...

Se trata de una estructura, no de un tipo simple-atómico y puede ser cambiado repentinamente, en cualquier punto del programa MQL, incluyendo el momento de obtener el valor.
Resulta que para abordar esta estructura tenemos que introducir un sincronizador.

¿pero en el probador _LastTick no puede cambiar en ningún punto del programa MQL?

si es así, entonces dé esa solución sólo para los probadores, donde la velocidad de los cálculos es lo más importante

[Alexey Navoykov]

Igor Makanu:

¿pero en el probador _LastTick no puede cambiar en ningún punto del programa MQL?

si es así, entonces dé una solución de este tipo sólo para el probador donde la velocidad de cálculo es lo más importante

Entonces, ¿qué le impide solicitar este tick una vez en el manejador OnTick, y luego trabajar con los datos obtenidos? Prácticamente no cuesta nada. ¿Por qué debería solicitarlo 100 veces (como en las pruebas anteriores), creando artificialmente frenos en un lugar parejo? Entonces, se sugiere resolver el problema de un código EA torcido complicando el trabajo interno de MT. ¿O tiene algunas medidas normales?

[fxsaber]

Alexey Navoykov:
Entonces, ¿qué le impide solicitar este tick en el manejador OnTick una vez y luego trabajar con los datos recibidos?

La escasa cualificación de los creadores de EA con la que se cargan Market y Cloud es un obstáculo.

[Maxim Kuznetsov]

Alexey Navoykov:
Entonces, ¿qué impide solicitar el tick una vez en el manejador OnTick, y de seguir trabajando con los datos recibidos? Prácticamente no cuesta nada. ¿Por qué volver a solicitarlo 100 veces (como en las pruebas anteriores), creando artificialmente frenos en el lugar? Entonces, se propone resolver el problema de un código EA torcido complicando el trabajo interno de MT. ¿O tiene algunas medidas normales?

Los eventos a ser manejados por "OnTick" son recibidos externamente en alguna cola con prioridades. En otros manejadores, es útil asegurarse de que no se han producido nuevos eventos de este tipo, de lo contrario los datos del tick anterior no son válidos/están desactualizados.

[Igor Makanu]

Alexey Navoykov:
Entonces, ¿qué te impide solicitar este tick una vez en el manejador OnTick y luego trabajar con los datos resultantes? Prácticamente no sirve para nada. Para qué molestarse en solicitarlo 100 veces (como en las pruebas anteriores), creando artificialmente un freno en el momento.

Esto es exactamente lo que hago en el probador

Alexey Navoykov:
Es decir, se supone que el problema de un código EA torcido se resuelve complicando el funcionamiento interno de la MT. ¿O tiene algunas medidas normales?

Bueno, el código está determinado por las prácticas comunes de codificación, mira el QB y el uso de las líneas de seguridad en estos ejemplos

No uso SB, llevo meses midiendo con un perfilador y buscando soluciones, había un hilo sobre pruebas de velocidad, en parte tirando a soluciones alternativas

la normalidad de la medición ... es una pendiente resbaladiza que tendrá que ser tratado con seriedad, estoy contento con mi EA para la optimización, había un pase a los 18 meses 6 seg, ahora 2,5 seg , imho he hecho un buen trabajo en mí ))))

[A100]

Según los materiales de .... han surgido las siguientes consideraciones:

Dado que UninitializeReason() puede ser llamado en cualquier parte de un programa, en particular en OnInit() (y si no se pretendía hacer tal llamada, el ámbito podría ampliarse)

Se sugiere:

Si el valor de la variable _UninitReason se genera antes de llamar a OnDeinit(),

y si no se puede definir el motivo de la desinicialización previa del EA (REASON_PROGRAM, REASON_REMOVE, etc.)

debe ser indefinido (-1) antes de esta llamada. Esto es ahora 0, es decir, efectivamente REASON_PROGRAM

Si el EA se reinicia completamente(REASON_RECOMPILE, REASON_ACCOUNT, REASON_CLOSE, etc.), entonces

parece posible establecer la variable _UninitReason a un valor apropiado (REASON_RECOMPILE, REASON_ACCOUNT, REASON_CLOSE, etc.) al iniciar una nueva instancia de un programa,

no 0 como en la actualidad, es decir, efectivamente REASON_PROGRAM

Si un Asesor Experto se reinicia parcialmente (REASON_CHARTCHANGE, etc.), la variable _UninitReason en OnInit() sigue siendo igual al valor correspondiente (REASON_CHARTCHANGE, etc.),

y no es necesario ningún cambio

[Sergey Dzyublik]

Error de compilación de MT5 (compilación 2450) para la declaración directa del método de la clase de plantilla.

template<typename T>
class A{};


class B{
public:
   template<typename T>
   void test(A<T> &a);
};

template<typename T>
void B::test(A<T> &a){}   // 'test' - member function already defined with different parameters 


void OnStart(){ 
   B b;
} 

[Artyom Trishkin]

Al reiniciar el terminal, escribe de forma continua y sin parar en el registro de grabaciones

2020.05.24 03:36:03.342 HistoryBase     'GBPUSD' 1 invalid bars removed

El tiempo de la barra de historia en el registro aumenta constantemente. El gráfico diario de GBPUSD está abierto y se mueve - cero, la primera y la segunda barra se borran/crean. Y así se va dando vueltas y más vueltas.

Aquí estoy esperando. ¿Se llenará todo el SSD con estos registros o se detendrá por fin...

La bitácora de ayer está en el trailer.