Características del lenguaje mql5, sutilezas y técnicas - página 113

[A100]

pavlick_:

No veo por qué mi solución es peor, la pondré aquí también:

Porque originalmente era una actuación de "mira cómo lo hago" y requería exactamente la solución que se había pensado de antemano. Y el tuyo no encajaba en la producción.

Pero incluso el director no tuvo en cuenta que, según la documentación, el orden de cálculo de los parámetros no está garantizado

[Alexey Navoykov]

A100:

Pero incluso el director no tuvo en cuenta que, según la Documentación, el orden de cálculo de los parámetros no está garantizado.

Para ser justos, la documentación de MQL lo describe:

Nota

Hay que recordar que los parámetros se pasan a la función al revés, es decir, se calcula y se pasa primero el parámetro más reciente, luego el penúltimo, y así sucesivamente. El parámetro que viene primero después del paréntesis de apertura se calcula y se transmite en último lugar.

Desde el punto de vista de C++ esto es, por supuesto, un comodín, pero si es una regla documentada en MQL, podría estar bien, si usted no planea portar su código en el futuro. Y si lo hace, puede asegurar este lugar marcando #ifdef __MQL__.

[Alexey Navoykov]

A100:

El orden de cálculo de los parámetros no está garantizado

Acabo de prestar atención a su enlace. Efectivamente, no está garantizado. Qué MQL tan contradictorio ))

[A100]

Alexey Navoykov:

Acabo de prestar atención a su enlace. Efectivamente, allí no está garantizado. Qué polémica MQL ))

En x32 revertir (creo que va a salvar), porque hay un enlace directo a la pila. Mientras que en x64 no tiene sentido la inversa y por eso no hay garantías para el futuro... además se ve poco natural allí

Ni siquiera me sorprendería que el orden fuera diferente con y sin optimización

[fxsaber]

Por todas las opciones ofrecidas, me gustaría dar las gracias. Has ayudado constructivamente a resolver un problema práctico.

La tarea estaba bien demostrada que no funcionaría si void TimeCurrent() fallaría. El vacío en su forma actual es capaz de paralizar muchas cosas.

[Vladimir Pastushak]

Quiero llamar al método padre

Aquí está el código, ¿qué estoy haciendo mal?

//+------------------------------------------------------------------+
class A
  {
public:
   virtual int Test_A()
     {
      return 100;
     }
  };
//+------------------------------------------------------------------+
class B :public A
  {
public:
   virtual int Test_A()
     {
      return 200;
     }
  };

B b;
//+------------------------------------------------------------------+
void OnStart()
  {
   Comment (A::b.Test_A());
  }
//+------------------------------------------------------------------+

[TheXpert]

Vladimir Pastushak:

Quiero llamar a un método padre

la sintaxis correcta es así:

b.A::Test_A()

pero en mql no hay ni bien ni mal.

Pero la pregunta es más para ti - si una función necesita ser llamada desde una derivada, ¿por qué ponerla en una función virtual base?

[pavlick_]

fxsaber:

La tarea demostró bien que si el void TimeCurrent(), nada funcionaría. El vacío en su forma actual es capaz de mutilar muchas cosas.

De un vistazo:

#define  MACROSV(NEW_HANDLE_, VOIDFN_) \
do{                                   \
   int prev=GetHandle();              \
   if(SelectHandle(NEW_HANDLE_))      \
      VOIDFN_;                        \
   SelectHandle(prev);                \
}while(false)

Dos macros no parecen hacer mucho daño. Algo más elegante, por el poder de μl, no se me ocurre.

[Alexey Navoykov]

pavlick_:

De lo que me viene a la cabeza:

¿Por qué hacer... mientras? Las llaves de la rótula son suficientes.

[pavlick_]

Alexey Navoykov:
¿Por qué hacer... mientras? Las llaves de la rótula son suficientes.

Para que funcione:

if(...)
   MACROSV(...);
else
{
}