OOP, plantillas y macros en mql5, sutilezas y usos - página 6

[Alexey Navoykov]

Alexey Viktorov:

Aquí está.

¿Así que todos sus códigos están hechos con muletas? No es nada personal.

Sí, aproximadamente. Porque MQL no tiene OOP en toda regla. Además hay un montón de bugs, de los que informo regularmente, pero sin éxito. Y tengo que defenderme de los bugs con muletas, qué le voy a hacer.

[Ilyas]

Así es como lo hacemos.

Si la variable estática se inicializa con una constante, esta inicialización se realizará en la etapa de inicialización global, como antes
En caso contrario (llamada o inicialización de variables), la variable estática se inicializará en la primera referencia (será como en C++), esta referencia en sí misma se envolverá en una condición con variable/bandera global implícita, por ejemplo

para el código MQL:

class CFoo { };

void func(bool f)
  {
   if(f)
     {
      static CFoo foo;
      foo.MakeMeHappy();
     }
  }

Se generará el siguiente pseudocódigo

CFoo static_func_foo={}; // zeromem only
bool static_func_foo_init=false;

void func(bool f)
  {
   if(f)
     {
      if(!static_func_foo_init)
        {
         static_func_foo.CFoo();  // constructor call
         static_func_foo_init=true;
        }

      static_func_foo.MakeMeHappy();
     }
  }

[Ilya Malev]

Alexey Navoykov:

Aún así, tendrás que separarlos de alguna manera en la función.

No necesariamente y no siempre. No voy a poner ejemplos, para no ensuciar el hilo.

[Alexey Navoykov]

Ilyas:

Así es como vamos a hacerlo.

¡Grandes noticias! Los dioses han escuchado nuestras plegarias después de todo).

[Alexey Viktorov]

Alexey Navoykov:
Sí, más o menos. Porque MQL no tiene OOP en toda regla. Además hay un montón de bugs, de los que informo regularmente, pero sin éxito. Y contra los bugs me tengo que defender con muletas, qué se le va a hacer.

Me has confundido. Si en ... leer sus palabras

Foro sobre comercio, sistemas de comercio automatizados y pruebas de estrategias

Peculiaridades de mql5, consejos y trucos

Alexey Navoykov, 2019.01.25 11:44

Si los parámetros son de diferentes tipos, es razonable hacer varios métodos sobrecargados con los tipos correspondientes. De todas formas hay que compartirlos en funciones, así que es mejor dividirlos en funciones separadas, que hacer un lío, que además lleva tipo anónimo, es decir, puedes pasarle por error cualquier cosa y obtener un error de compilación dentro de la librería, que no es bueno. O puede que ni siquiera lo consigas, que es doblemente malo).

En resumen, en la POO completa las funciones de plantilla son una muleta (con pocas excepciones).

Y no hay OOP en toda regla en MQL... ¿Incluso faltan las muletas? No entiendo nada en absoluto.

[Ilya Malev]

MQL está bien con OOP, y si se añade la herencia múltiple (al menos para las interfaces, porque son inútiles en su forma actual), será perfecto.

[Alexey Navoykov]

Ilya Malev:
MQL está bien con la POO, si añaden la herencia múltiple(al menos para las interfaces, porque son inútiles en su forma actual), será perfecto.

Entonces, las interfaces son la base de la POO normal, y tú dices que todo está bien en MQL.

[Ilya Malev]

Alexey Navoykov:

Así que las interfaces son la base de la POO normal, y sin embargo dices que todo está bien en MQL.

La base de la POO normal es el polimorfismo, no las interfaces. Las interfaces son la base de una determinada estructura de clases. En general, me encantaría hablar de estos temas, pero me temo que este hilo no es el lugar para ello.

[Alexey Navoykov]

Ilya Malev:

La base de la POO normal es el polimorfismo, no las interfaces. Las interfaces son la base de una determinada estructura de clases. En general, estaría encantado de discutir estos temas, pero me temo que esta rama no es adecuada para ello.

Estamos hablando de particularidades del lenguaje MQL y la ausencia de herencia múltiple es un rasgo bastante característico).

Ok, la base es ciertamente el polimorfismo, pero sin interfaces separadas no es conveniente en el uso. Esto a menudo conduce a pasar objetos como argumentos de la plantilla en lugar de interfaces.

He descrito aquí mi variante de simular múltiples interfaces. En consecuencia, una clase puede ser declarada como

class A : public Interface1<Interface2<Interface3<CBase>>>
{
 ...
};

[Ilya Malev]

Alexey Navoykov:

Estamos hablando de peculiaridades del lenguaje MQL y la ausencia de herencia múltiple es toda una peculiaridad).

Ok, la base por supuesto es el polimorfismo, pero sin interfaces separadas no es conveniente en el uso. Esto a menudo conduce a pasar objetos como argumentos de la plantilla en lugar de interfaces.

He descrito mi variante de imitar múltiples interfaces aquí. En consecuencia, una clase puede ser declarada como tal:

En mi opinión, no todo es malo. No hay tantas interfaces principales básicas en C# como para que sus métodos no puedan reducirse a una superclase básica y luego heredarse.

P.D. Implementar algo múltiple a través de construcciones como <<<<>>>> es un poco pesado. Es mejor hacer las funciones a través de operadores, por ejemplo, a==b llama a.compareto( b ), a[comparer]==b llama a comparer.compare(a,b) etc.