Errores, fallos, preguntas - página 1953

[fxsaber]

Alexey Navoykov:

En general, admito con pesar que el compilador MQL no es tan inteligente como creía). Incluso diría que no es nada inteligente. ) Intenté hacer algunos ejemplos sencillos y resultó que incluso si creo un objeto ficticio, que no se usa en ninguna parte y no hace nada, el compilador no se preocupa por él. No está optimizado en absoluto. Estoy juzgando sólo por la velocidad. Y por alguna razón funciona más lento en las nuevas construcciones que en las antiguas.

Los desarrolladores son conscientes de ello. Pero esta optimización por parte del compilador está lejos de ser la prioridad de las tareas a resolver.

También existen estas ambigüedades del compilador.

[Alexey Navoykov]

fxsaber:

Los desarrolladores son conscientes de ello. Pero esta optimización por parte del compilador dista mucho de ser una prioridad de las tareas a resolver.

Sí, pero es que es increíble: antes presumían mucho aquí de que habían elevado la calidad del optimizador a cotas sin precedentes, pero en realidad no puede manejar ni siquiera cosas tan sencillas. Por no hablar de los más complejos.

[Alexey Navoykov]

fxsaber:

Por eso propongo añadir a OnTesterInit la posibilidad de cambiar la tabla de pases por defecto:

int PassesSet( const int Index, const MqlParam& Parameters[] );

Supongo que los conjuntos de parámetros en sí no se almacenan en el sistema, sino que se calculan por el número único de la combinación (ahora coincide con el número de pase). Por lo tanto, sólo es posible cambiar el orden de las combinaciones, pero no su composición. Así, en este caso, sería algo como SwapPasses(long index1, long index2).

Pero podría estar equivocado.

[fxsaber]

Alexey Navoykov:

Supongo que los conjuntos de parámetros en sí no se almacenan en el sistema, sino que se calculan utilizando el número de combinación único (ahora coincide con el número de pase). Por lo tanto, sólo se puede cambiar el orden de las combinaciones, pero no su composición. Es decir, en este caso sería algo como SwapPasses(long index1, long index2).

Este puede ser el caso. Ahora el orden todavía puede ser influenciado de alguna manera por las líneas de entrada Swap en la fuente de EA.

[Stanislav Korotky]

fxsaber:

Este puede ser el caso. Ahora el orden puede ser influenciado de alguna manera por las líneas de entrada Swap en el código fuente de EA.

Mata el algoritmo de optimización - es como optimizar en dirección aleatoria.

[fxsaber]

Stanislav Korotky:

Esto mata el algoritmo de optimización - es como optimizar en una dirección aleatoria.

En primer lugar, estamos hablando de un rebasamiento total.

[[Eliminado]]

Estoy aprendiendo poco a poco OOP y me he encontrado con una cosa no obvia.

Existe una clase A, cuyos campos son objetos de otra clase B.

En la clase A se llama a un método constante que devuelve un objeto de la clase B.

Después, se llama a un método de la clase B, que borra los parámetros del objeto devuelto.

Se ve así (el ejemplo está simplificado, escrito en el navegador):

class B
{
private:
   int m_width;
   int m_length;
public:
   void Reset() { m_width = 0; m_length = 0; }
}
class A
{
private:
   B m_member;
public:
   B GetBMember() const { return( m_member ); }
}
//---
A obj;
obj.GetBMember().Reset();

Como resultado, resulta que Reset() no funciona, es decir, los campos m_member no se borran.

Pregunta: ¿no debería el compilador informar (error/advertencia) en tiempo de compilación de que se está llamando a un método no constante para un objeto constante (o algo así)?

[Sergey Dzyublik]

Alexey Kozitsyn:

Pregunta: ¿no debería el compilador informar (error/advertencia) en tiempo de compilación de que se está llamando a un método no constante para un objeto constante (o algo así)?

Tal vez la razón sea una llamada implícita al constructor de copia como resultado de la llamada aReset para un objeto temporal.

[[Eliminado]]

Sergey Dzyublik:

Tal vez la razón sea una llamada implícita al constructor de copia como resultado de la llamada aReset para un objeto temporal.

Gracias. Probablemente tengas razón, y el especificador const no afecta al resultado (no se produce ningún reinicio tanto con como sin él).

[Andrey Barinov]

Alexey Kozitsyn:

Estoy aprendiendo poco a poco OOP y me he encontrado con una cosa no obvia.

Existe una clase A, cuyos campos son objetos de otra clase B.

En la clase A se llama a un método constante que devuelve un objeto de la clase B.

Después, se llama a un método de la clase B, que borra los parámetros del objeto devuelto.

Se ve así (el ejemplo está simplificado, escrito en el navegador):

El resultado es que Reset() no funciona, es decir, los campos m_member no se borran.

Pregunta: ¿no debería el compilador informar (error/advertencia) en tiempo de compilación de que se está llamando a un método no constante para un objeto constante (o algo así)?

Devuelve los punteros.

class B
{
private:
   int m_width;
   int m_length;
public:
   void Reset() { m_width = 0; m_length = 0; }
}
class A
{
private:
   B m_member;
public:
   B * GetBMember() const { return( & m_member ); }
}
//---
A obj;
obj.GetBMember().Reset();