Tema interesante para muchos: las novedades de MetaTrader 4 y MQL4 - grandes cambios en camino - página 10
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
No hay que olvidar que tenemos un muy buen inliner en funcionamiento, que drena un montón de pequeñas funciones, por lo que no hay pérdida de velocidad.
Y en la mayoría de los casos, las llamadas a funciones virtuales a través de vtable se optimizan en llamadas directas. Este es uno de los métodos eficaces del optimizador. Lo cual, junto con el inlining múltiple, permite deshacerse casi por completo de las complejas llamadas de varios niveles y hacer que el código parezca plano.
No hay que olvidar que tenemos un muy buen inliner en funcionamiento, que drena un montón de pequeñas funciones, por lo que no hay pérdida de velocidad.
Y en la mayoría de los casos, las llamadas a funciones virtuales a través de vtable se optimizan en llamadas directas. Este es uno de los métodos eficaces del optimizador. Eso, junto con el inlining múltiple, le permite deshacerse casi por completo de las complejas llamadas de varios niveles y hacer que el código parezca plano.
:) divertido. Y nadie discute que el compilador optimiza perfectamente el código, sólo estoy demostrando a mi amigo por qué no me bajo antes de SB.
Bien, pongamos ejemplos:
se sustituye en la práctica por una simple función estándar
CopyBuffer(...);Tenemos el arte por el arte. Y así en cada elemento que hace algo (el resto, como comprenderás, se escribe para que los elementos finales funcionen).
Sí, estoy de acuerdo con la versatilidad, sí, estoy de acuerdo con el código bien estructurado (se puede decir, es una muestra para el análisis).
Pero, ¿cuál es la esencia de esto? El punto es que esta biblioteca es principalmente necesaria para el Asistente MQL5 y como un tutorial sobre OOP.
Simplemente estoy haciendo entender al camarada por qué no me caigo frente al SB.
Sí, sí, vuelvo a insistir: no tengo ninguna objeción seria a ninguno de sus argumentos. Una discusión sobre esto sería más religiosa que objetiva.
Bueno, sólo en tu ejemplo, personalmente, y en MI CASO, encuentro más aceptable la primera variante del código, por todas esas inclusiones multinivel que proporcionan la compatibilidad del indicador con todas las interfaces, empezando por CObject y hasta CiCustom.
Pero, por otro lado, todas las series temporales y los indicadores se crean bajo demanda, se apilan en una única colección y están disponibles para todos los usuarios. Y cuando sólo necesitamos copiar un búfer una vez, nos preguntamos por qué molestarnos con todo este problema.
Así que en un caso simple, por supuesto, sería mucho más fácil usar CopyBuffer().
¿Pero qué pasa si tenemos una docena de usuarios de un determinado buffer? En mi caso - todos lo pedirán, el buffer se creará y todos los demás obtendrán una referencia a él. Y si usamos CopyBuffer() "directamente" - tendré diez copias en lugar de una. Y cuando usas CopyBuffer() de forma más astuta, obtienes cosas con el seguimiento de quién y qué búfer se asignó, lo que es bastante equivalente en coste a la encapsulación que has mencionado.
Personalmente, estoy a favor de la razonabilidad: no tiene sentido hacer un gran esfuerzo por la OOP para un solo lugar. Si tenemos muchos usuarios, el enfoque OOP, en mi opinión, se justifica.
Entonces es el momento de introducir excepciones para que un código pueda ser compilado tanto para mql4 como para mql5.
La cuestión de la unificación está en ciernes.
Estaba pensando que al fusionar dos lenguajes, las directivas de compilación condicional como #ifdef son absolutamente necesarias - esto simplificaría la unificación de códigos entre las dos plataformas, y la API dependiente de la plataforma se definiría en tiempo de compilación.
Por desgracia, no. El probador seguirá siendo de un solo hilo y sin MQL5 Cloud Network.
No hay que olvidar que tenemos un muy buen inliner en funcionamiento, que drena un montón de pequeñas funciones, por lo que no hay pérdida de velocidad.
Y en la mayoría de los casos, las llamadas a funciones virtuales a través de vtable se optimizan en llamadas directas. Este es uno de los métodos eficaces del optimizador. Lo cual, junto con el inlining múltiple, permite deshacerse casi por completo de las complejas llamadas de varios niveles y hacer que el código parezca plano.
Ahhhh... Ahora entiendo por qué uno de mis errores más frecuentes al escribir un programa es "La función debe tener un cuerpo".
Es el inliner que requiere... Me preguntaba porque pensaba que una cabecera de función es suficiente para compilar un módulo, pero no... Necesitas un cuerpo...
Eso es bueno.
Ahhhh... Ahora entiendo por qué uno de mis errores más frecuentes al escribir un programa es "La función debe tener un cuerpo".
Es el inliner que requiere... Me preguntaba porque pensaba que una cabecera de función era suficiente para compilar un módulo, pero no... Necesitas un cuerpo...
Es correcto, pero no tiene nada que ver con el optimizador.
Si has descrito el prototipo de una función de clase, el cuerpo debe estar ahí. Incluso si está vacío.
Renat, sugiero que en MT4 se haga el control de la visibilidad de las posiciones en el gráfico no en los parámetros generales del terminal, sino por separado para cada gráfico (como se hacía en MT5).
Mi solicitud al SR sobre este tema lleva dos meses inactiva.
Renat, sugiero que en MT4 se haga el control de la visibilidad de las posiciones en el gráfico no en los parámetros generales del terminal, sino por separado para cada gráfico (como se hacía en MT5).
Mi solicitud al SR sobre este tema lleva dos meses inactiva.