¿Se demandará OOP en MQL5? - página 3
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
Al menos el aprendizaje de MQL4 no será una pérdida de tiempo. Si sólo has utilizado indicadores estándar, la conversión, según tengo entendido, no será muy difícil.
Creo que el programador medio semiprofesional no necesitará OOP en MQL5.
Si tengo la impresión de que la velocidad será mayor en todos los aspectos, prefiero no fijarme en esos indicadores que pueden resolver grandes problemas. Repito: no soy un profesional.
Aunque, ¿quizás ahora los entusiastas utilicen el MQL5 para simular la aparición de la vida a partir del caldo primario? ;)
P/S Se olvidó. Funciones de manejo de eventos. Gud.
... devuelve una interfaz (una clase con funciones virtuales). En el caso de uso "descoordinado" conmigo, devuelve una interfaz stub (con fallos de cálculo no muy evidentes).
¿Puedes hacerlo sin decir palabrotas? Las mujeres a veces vienen al foro aquí.
Habrá un beneficio de protección: la biblioteca EX5 devuelve una interfaz (una clase con funciones virtuales). En caso de uso "descoordinado" conmigo devuelve el stub de la interfaz (con errores de cálculo no muy evidentes).
Si vale la pena, lo descifrarán, y la interfaz con los humanoides limpios no ayudará :)
Por lo tanto, la protección es la misma que en otros lugares: no hay acceso físico al código, además de una demora necesaria para la TS específica con la revisión de las operaciones (el inversor de capital puede recibir tiempo real).
Bueno, la OOP en los EAs es algo muy valioso, empezando por los eventos, la posibilidad de un soporte competente y la puesta a punto, etc. Por supuesto, no entiendo por qué C# no era una buena idea, porque la ausencia de un marco MQL5 con declaraciones claras de espacio de nombres, así como un lenguaje no estándar + inmaduro, requerirá más esfuerzos de lo inicialmente razonable por parte de todos :(
Ya no tienen OOP en su núcleo (aunque la OOP absoluta es prácticamente inutilizable). Deberíamos haber creado clases abstractas desde el principio y utilizar la herencia y el polimorfismo para llegar a los objetos reales. Por ejemplo, para crear una clase base abstracta para indicadores personalizados con métodos y propiedades abstractas. Es mejor construir un árbol jerárquico de clases: un árbol para los objetos gráficos, para el trabajo con la cuenta, para los horarios y el acceso a las series temporales, etc. Y en el caso de los procedimientos y funciones predefinidos, sólo deben dejarse las rutinas elementales que requieran velocidad. Entonces podría ampliar las capacidades de la plataforma desde cualquier nivel de abstracción, lo que reduciría el tamaño del código y mejoraría su legibilidad y facilidad de comprensión para otros programadores. Y en MT5 ya se han implementado cosas bastante complejas a nivel de procedimientos (de hecho toda la plataforma está preparada para su uso) y no he visto la posibilidad de acceder por punteros al menos a los descriptores de las estructuras internas creadas, lo cual es muy limitante (a juzgar por la ayuda). En general, la necesidad de OOP es cuestionable, con una implementación de este tipo podría limitarse a las estructuras y la colocación dinámica. La programación orientada a objetos debe estar apoyada desde abajo por una jerarquía de clases bien desarrollada.
Sí. Eso es lo que estoy diciendo. La forma en que se hace, en mi opinión, no es muy útil. Para eso está esto. Pero, aun así, ¿quizás haya otras opiniones?
Whistles'n'Bells, definitivamente. Sin embargo, si hay algún soporte para objetos externos, es genial.
Sin espacios de nombres, no es realmente factible.
Sin espacios de nombres, no es realmente factible proporcionar un soporte adecuado.
Se puede prescindir de estas últimas novedades de Microsoft. Pero no se puede prescindir de estas últimas cosas de fantasía como las ' bibliotecas de interfaz ' al menos mientras hablamos de winnda. En realidad es una pena que los desarrolladores de MT parezcan haber jurado una lealtad eterna a la melkomsoft hasta la tumba y no prestar atención al resto. Mi instinto me dice que será un verdadero dolor de cabeza hacer que incluso la MT5 completamente sin pecado funcione en Linux a través de Wine.