OOP, plantillas y macros en mql5, sutilezas y usos - página 5
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Sobre el multipase - apresurado, ingenuamente pensó que el mcl lo permitiría
Ну вот я с этого и начинал разговор тут. Планировал тоже заменять все статики на глобалы (хоть это и жесть конечно). Но как показано выше, с шаблонами такое не прокатит. С макросами тоже. А я всё это широко применяю. Поэтому и сделал свою реализацию. Хотя она конечно не решает всех проблем. Динамические массивы по-прежнему нельзя инициализировать, константные типы тоже. Поэтому их однозначно придётся выносить на глобальный уровень
También uso mucho las plantillas y las macros, pero considero las funciones libres sólo como elementos arquitectónicos auxiliares (y generalmente indeseables). Cuando todas las implementaciones se empaquetan dentro de los objetos y la estática se declara sólo a nivel de clase, aparecen errores molestos salvo que a veces es difícil entender la lógica de su correcta secuencia de declaraciones, por lo que el compilador no jura...
Así que aquí hay variables. Y con las funciones, sí, es multipasable, por lo que todo era correcto. El problema surge precisamente por el orden de inicialización de las funciones. En definitiva, en C++ hay un orden estricto que se aplica a variables, funciones y tipos. Y en MQL todo es diferente.
Los pases múltiples son malos en cualquier caso - puede encontrar recursión, bloqueos, etc. Pero el lado positivo es que se puede hacer. Por lo tanto, sólo sabiamente, con cautela (es decir, la declaración hacia adelante), y no como ahora con el compilador multi-pass - como si para cualquier función declaración hacia adelante se hace, tarde o temprano este rastrillo golpeará su frente.
El multipaso es malo en cualquier caso: puedes encontrarte con recursividad, bloqueo, etc. Pero es posible hacer la declaración hacia adelante en el lado positivo. Por lo tanto, sólo sabiamente, con cuidado, y no como ahora con compilador multipaso - como si para cualquier declaración de función hacia adelante se hace, tarde o temprano este rastrillo golpeará su frente.
Estoy de acuerdo. Este tema se discutió un poco antes. Es lo que a muchos aquí les gusta del lenguaje: que no se moleste en el orden de declaración de las funciones. No hace falta decir que yo mismo me alegré de ello hace tiempo). Pero su tedio me irritaba en el lado positivo. Pero con la experiencia llega la comprensión.
También uso mucho las plantillas y las macros, pero considero las funciones libres sólo como elementos arquitectónicos auxiliares (y generalmente indeseables). Cuando todas las implementaciones se empaquetan dentro de los objetos y las estáticas se declaran sólo a nivel de clase, aparecen errores molestos, excepto que a veces es difícil entender la lógica de su secuencia correcta, por lo que el compilador no jurará...
Estoy de acuerdo, si todo está claramente alineado en la POO, entonces no sólo las funciones libres no son necesarias, sino también los métodos de plantilla.
Los métodos de plantillas son necesarios siempre que no se quiera escribir un montón de código repetitivo, ya sea OOP o no OOP. Otra cosa son las funciones libres: son estilos de programación diferentes.
Los métodos de plantillas son necesarios siempre que no se quiera escribir un montón de código repetitivo, ya sea OOP o no OOP
En la programación orientada a objetos (OOP), las interfaces se inventaron con este fin.
Las interfaces son un poco diferentes. Si quiero que el mismo código haga el mismo trabajo con diferentes tipos dependiendo de la clase de parámetro (sin declarar clases adicionales), las interfaces no ayudarán.
Las interfaces son un poco diferentes. Si quiero que el mismo código haga el mismo trabajo con diferentes tipos dependiendo de la clase de parámetro (sin declarar clases adicionales), la interfaz no ayudará.
Si los parámetros son de diferentes tipos, entonces tiene sentido hacer varios métodos sobrecargados con los tipos correspondientes. Aún así, tendrás que separarlos de alguna manera en la función. Así que es mejor dividirlos en funciones separadas, que crear un lío que también toma un tipo impersonal, es decir, por error puedes pasar cualquier cosa en él y obtener un error de compilación dentro de la biblioteca, lo cual no es bueno. Y tal vez incluso no, lo cual es doblemente malo).
En resumen, en la POO completa las funciones de plantilla son una muleta (con pocas excepciones)
En resumen, las funciones de plantilla son una muleta en la POO completa.
Así que aquí estamos.
Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading
Características del lenguaje mql5, consejos y trucos
Alexey Navoykov, 2019.01.25 10:11
Así es como empecé la conversación aquí. Yo también tenía pensado sustituir todos los estáticos por globales (aunque es una cosa cruel, claro). Pero como se ha mostrado arriba, no funcionará también con las plantillas y las macros. Y yo las uso mucho. Por eso hice mi propia implementación. Aunque no resuelve todos los problemas. Los arrays dinámicos siguen sin poder ser inicializados, ni tampoco los tipos constantes. Por eso definitivamente tendrán que ser globalizados.