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

[Alexey Navoykov]

Ilya Malev:

Tengo "stack overflow" )

Supongo que es una cucaracha después de todo...

Bueno, no es el compilador, sino en tiempo de ejecución. El compilador debería reaccionar.

Esto es lo que he probado en VS 2010:

class A
 {
  public:
   virtual int f2() = 0;
 };

class B : public A
{
 public:
  virtual int f2() { return A::f2(); }
};

B b;

Me sale un error de compilación: Error 1 error LNK2001: símbolo externo no resuelto "public: virtual __thiscall A::f2(void)".

Pero Metaeditor no dirá una palabra. No es bueno.

[Ilya Malev]

Resulta que llamar a una función antecesora con = 0 se convierte en llamarse a sí misma. Si detectas este error tú mismo, podrías beneficiarte de él...

[Alexey Viktorov]

Alexey Navoykov:

Así es como debería reaccionar el compilador.

He probado esto en VS 2010:

Me sale un error de compilación: Error 1 error LNK2001: símbolo externo no resuelto "public: virtual __thiscall A::f2(void)".

El metaeditor no dirá nada. No es bueno.

Alexey, por favor, explícame, ¿por qué si mql es una copia de C, debe ser absolutamente idéntico y un paso a la izquierda, un paso a la derecha - pelotón de fusilamiento?

¿Sólo porque los desarrolladores fueron descuidados? Pero cualquier lenguaje se construye con bucles y condiciones. Todo lo demás está en el tráiler. ¿Por qué nadie exige que cualquier otro lenguaje sea similar a C en la parte de POO o en cualquier otro aspecto?

[Alexey Navoykov]

Alexey Viktorov:

Alexey, ¿puedes explicarme con tus dedos por qué si mql es como C, entonces debe ser absolutamente idéntico y un paso a la izquierda, un paso a la derecha - pelotón de fusilamiento?

¿Sólo porque los desarrolladores fueron descuidados? Pero cualquier lenguaje se construye con bucles y condiciones. Todo lo demás está en el tráiler. ¿Por qué nadie exige que cualquier otro lenguaje sea similar a C en la parte de POO o en cualquier otro aspecto?

No se trata de ser completamente idéntico. Se trata de que la funcionalidad que se implemente debe funcionar correctamente y de forma coherente. Pero primero grita: muéstrame otro lenguaje que funcione de forma diferente. Y luego cuando se pone como ejemplo C++, que funciona de forma diferente (correctamente), empiezas a despotricar sobre cómo MQL no es C++ y no debería ser idéntico. Deberías decidirte

[Dmitry Fedoseev]

Alexey Viktorov:

¿Puedes mostrarnos un ejemplo en el que todo esto pueda facilitar la escritura de código, acortarlo o, al menos, protegerlo de errores? Y por favor, no utilices funciones abstractas, sino las más cercanas a las condiciones reales de trading en un EA o indicador.

De ninguna manera. Los chicos sólo intentan hacer realidad sus fantasías.

[Nikolai Semko]

Dmitry Fedoseev:

De ninguna manera. Los chicos sólo intentan convertir sus fantasías en realidad.

Me parece que es un ejercicio muy útil: convertir la fantasía en realidad. Ese es el objetivo del desarrollo.

Un debate muy esclarecedor. (Gracias.

[Ilya Malev]

Alexey Navoykov:

Sí, pero hace tiempo que utilizo una opción alternativa: todas las interfaces se diseñan originalmente como una clase de plantilla intermedia:

De este modo, se puede crear una cadena de herencia formada por cualquier número de estas interfaces. Sí, por supuesto que no se puede hacer dynamic_cast con ellos, pero no es necesario tan a menudo. La tarea principal es pasarlos a funciones.

Lo he leído con atención, es un movimiento interesante, por cierto. No se me había ocurrido antes =) Yo también experimentaré, en mi tiempo libre...

[Alexey Navoykov]

Nikolai Semko:
Para mí, un ejercicio muy útil - para estirar la fantasía en la realidad. Ese es el objetivo del desarrollo.

Un debate muy esclarecedor. Gracias.

Y lo más importante, ¡fructífera! Los desarrolladores sí nos han escuchado y han decidido arreglar este fallo con el que todo el mundo ha estado tropezando durante años.

Pero la actitud destructiva de algunos usuarios del foro es ciertamente sorprendente: no se desarrollan y tratan de obstaculizar a los demás con notable persistencia.

[Ilya Malev]

>> Sí, claro que no se puede hacer dynamic_cast con ellos, pero no es una necesidad tan frecuente.

Por qué no lo haces tú, no hay problema ) Pero entonces aparece tu principal pesadilla: la no detección de errores de fundición en la fase de compilación :)

[Alexey Navoykov]

Ilya Malev:

>> Sí, claro que no se puede hacer dynamic_cast con ellos, pero no es una necesidad tan frecuente.

Por qué no lo haces tú, no hay problema ) Pero entonces aparece tu principal pesadilla: la no detección de errores de fundición en la fase de compilación :)

Al fin y al cabo, la cadena de herencia podría ser de cualquier manera: Interfaz<CBase> o Interfaz<C<B<A<CBase>>>>, hay innumerables variantes. Tendríamos que lanzar CBase de forma consistente a todas las posibles variantes, lo cual es poco realista.

Recuerdo haber planeado implementar el almacenamiento de información sobre las interfaces en el propio objeto de clase, y además de las almohadillas de interfaz existentes, hacer clases de interfaz independientes, que funcionarían como una envoltura sobre nuestra almohadilla. Pero luego llegué a la conclusión de que todo esto era innecesario y sin necesidad. En la práctica, nunca he visto la necesidad de fundir una clase base a ninguna interfaz, simplemente no tiene ningún sentido. La única opción es averiguar si la clase soporta esta interfaz para fines de depuración, pero no necesitamos el casting para eso.