Preguntas sobre POO en MQL5 - página 66
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
He aquí la respuesta al porqué:
En el rectángulo rojo - se ha añadido una llamada aGetMicrosecondCount(), en el azul - una más. Por eso es casi igual.
¿Por qué te atreves a mostrarme el código? Sin el código, puedes meterte tus fotos de tiempo donde no brilla el sol.
Uy. Con acciones idénticas, sólo había un 30% de diferencia.
¿Quizás son las clases las que crean la sobrecarga? Por supuesto, el compilador debería, en cualquier caso, inlinear todo y cortar las cosas innecesarias. Tiene sentido señalar esto a los desarrolladores.
Ha funcionado. La estructura funcionaba a la misma velocidad que la función y la macro. Pero la clase... muy atrás.
Ha funcionado. La estructura funcionaba a la misma velocidad que la función y la macro. Pero la clase... muy atrás.
Yo mismo aconsejé cómo acceder a métodos/campos privados en SB y recogí este gancho en el foro, no recuerdo quién lo sugirió.
me sorprendió descubrir que estaba dando consejos como siempre sin atenerse a la terminología, no era un gancho sino un antipatrón Público Morozovhttp://blog.kislenko.net/show.php?id=1775
)))
Yo mismo aconsejé cómo acceder a métodos/campos privados en SB y recogí este gancho en el foro, no recuerdo quién lo sugirió.
me sorprendió descubrir que estaba dando consejos como siempre sin atenerse a la terminología, no era un ganchosino un antipatrón Público Morozovhttp://blog.kislenko.net/show.php?id=1775
)))
ahí has dado un barril de miel a los negadores del patrón y a los amantes de la OO :-) Un patrón para conseguir lo que está oculto por consideraciones de diseño :-)
Alguien (alguien de los monstruos actuales de OO/C++), dijo muy razonablemente que el punto de fricción de OO es que la clase base debe proporcionar suficientes interfaces para todas las variaciones descendientes (prácticamente tener disponibles setters-getters a todos los campos, o todo en uno),
y los descendientes no deben crear funciones virtuales fuera del protocolo de los padres, sólo entonces vendrá la felicidad universal. Entonces el STL+boost generalizado realmente ahorra, las pruebas son útiles y reutilizables. Pero se convierte en un montón de clases, porque en lugar de nuevas funciones virtuales actúan todo tipo de proxies.
aquí has dado un barril de miel a los negadores del patrón y a los amantes de la OO :-) Un patrón para conseguir lo que está oculto por consideraciones de diseño :-)
Alguien (alguien de los monstruos actuales de OO/C++), dijo muy razonablemente que el punto de fricción de OO es que la clase base debe proporcionar suficientes interfaces para todas las variaciones descendientes (prácticamente tener disponibles setters-getters a todos los campos, o todo en uno),
y los descendientes no pueden crear funciones virtuales fuera del protocolo de los padres, sólo entonces vendrá la felicidad universal. Entonces el STL+boost generalizado realmente ahorra, las pruebas son útiles y reutilizables. Pero se convierte en un montón de clases, porque todo tipo de proxies actúan en lugar de nuevas funciones virtuales.
¿Qué tienen que ver los patrones y los amantes de la OO?
Alguien (alguien de los actuales monstruos de la OO/C++), dijo con bastante sensatez que el punto de fricción de la OO es que la clase base debe proporcionar suficientes interfaces para todas las variaciones de los descendientes (prácticamente tener disponibles setter-getters para todos los campos, o todo en blanco)