OOP vs. programación procedimental - página 24
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
1. Hay un criterio. El criterio principal es la velocidad de funcionamiento.
La visibilidad del código es un criterio equivocado.
Todo el mundo cambia urgentemente a asamblador..... pero rápido.... es cierto que lo que es rápido es la organización adecuada de todo el proyecto o la velocidad de las funciones individuales
Todo el mundo se mueve con urgencia a asambler..... pero rápido.... pero lo que sí es rápido es la organización adecuada de todo el proyecto o la velocidad de las funciones individuales.
Todo el mundo se mueve con urgencia a asambler..... pero rápido.... realmente lo que es rápido es la organización adecuada de todo el proyecto o la velocidad de las funciones individuales
No, sigue codificando a través del ***.
Bueno, no estoy de acuerdo.
La claridad del código es algo muy importante, porque un código claro es mucho más fácil de mantener y modificar.
Así es - escribí una función desnuda, y luego la "ofusqué", la hice no visible e incomprensible. Esta fue una decisión forzada. En este caso, era más importante para mí que toda la clase fuera transparente. He sacrificado la claridad de una función bastante trivial. Por supuesto, podría haber puesto el cuerpo de esta función en el archivo .mq5, pero creo que las interfaces no deberían estar divididas en dos archivos y deberían estar completamente descritas en el archivo de cabecera .mqh.
La velocidad también es algo que hay que tener en cuenta, pero no creo que debamos buscar la "velocidad a cualquier precio". Tiene que haber una suficiencia razonable.
Probablemente el mismo punto 3 para ti también
Llevo mucho tiempo programando. Desde el lanzamiento de MT3.
Desde entonces me siento más cómodo escribiendo en estilo procedimental en mql4. No tengo EAs en 1001 líneas. Además, sólo tengo algunas funciones almacenadas en bibliotecas.
Y en MQL5 uso la biblioteca estándar. Es algo conveniente.
Pero hay que optimizar el rendimiento para evitar llamar a funciones cada vez más pesadas. Recientemente, he estado modificando un EA de Mql4 a MQL5. He utilizado la biblioteca presentada aquí. Me llevó medio día averiguar todas las funciones y funcionó, pero la optimización fue muy lenta. He reducido el indicador a 2 barras y todo ha empezado a volar.
La conclusión es sencilla. Todo el mundo puede escribir en cualquier estilo. MQL no es realmente un lenguaje que requiera la optimización del código para ganar un par de milisegundos mediante la programación procedimental. Las tareas lógicas son más importantes. La forma en que se implementan no tiene prácticamente ningún efecto sobre la velocidad.
...
La conclusión es sencilla. Todo el mundo puede escribir en cualquier estilo. MQL no es realmente un lenguaje que requiera la optimización del código, para poder ganar un par de milisegundos utilizando la programación procedimental. Las tareas lógicas son más importantes. La forma en que se implementan no tiene prácticamente ningún efecto sobre la velocidad.
De manera tan discreta que es la programación procedimental la que proporciona un alto rendimiento. Llevo tres días mostrando un problema que sólo puede resolverse mediante POO sin ralentizaciones innecesarias.
La programación orientada a objetos nos permite separar conjuntos de variables del resto del código, lo que nos permite evitar el paso de parámetros a los métodos cuando se realizan cálculos dentro de una clase, y esto es un factor importante para la velocidad. Incluso si lo haces en estilo procedimental, tendrás que crear un gran número de variables globales, y como resultado la legibilidad del código es imposiblemente baja.
Se ha decepcionado tan suavemente que es la programación procedimental la que proporciona un alto rendimiento. Durante tres días he estado mostrando aquí un problema que sólo OOP puede resolver sin frenos innecesarios.
La programación orientada a objetos nos permite separar conjuntos de variables del resto del código, lo que nos permite evitar el paso de parámetros a los métodos cuando se realizan cálculos dentro de una clase, y esto es un factor importante para la velocidad. Incluso si lo hace en un estilo procedimental, tendrá que crear un gran número de variables globales, y como resultado la legibilidad del código es imposible.
La ganancia del estilo procedimental es insignificante, porque el código se inicia con cada tick en los Asesores Expertos. Y puede haber cientos o incluso decenas de milisegundos entre los ticks. Nunca me molesté con los indicadores. No he encontrado ningún beneficio real de los indicadores.
Creo que sería más conveniente escribir proyectos grandes usando OOP. Yo mismo prefiero utilizar estructuras, si tengo que guardar algo.
En este caso, el acceso a los datos está más claro y el menú desplegable es muy cómodo de utilizar. Si se sustituyen las estructuras por matrices, a menudo surgen confusiones y el número de matrices crece.
En mi post anterior ponía el énfasis específicamente en llamar a funciones pesadas. Por ejemplo, algún tipo de bucle que no necesite ser llamado en cada tick. Y tampoco hay que hacerlo en cada bar nuevo.
Ahí es donde se puede aumentar la ganancia de rendimiento real.
Sí. Es un debate divertido: Excavadora contra pala.
Supongo que si quieres plantar un árbol, es mejor una pala. Pero si quieres cavar un agujero, la retroexcavadora es probablemente mejor.
Sí. Es un debate divertido: Excavadora contra pala.
Supongo que si quieres plantar un árbol, es mejor una pala. Pero si quieres cavar un agujero, la retroexcavadora es probablemente mejor.
Sí. Es un debate divertido: Excavadora contra pala.
Supongo que si quieres plantar un árbol, es mejor una pala. Pero si quieres cavar un agujero, la retroexcavadora es probablemente mejor.