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
Algo que olvidaste sobre las estructuras y las clases (sin novedad): ambas destacan en la pila.
No hay que confundirlo con C++, está más cerca de Sharp
No hay que confundirlo con C++, está más cerca de Sharp
Esta es tu fantasía, no la realidad.
No deberías probar lo que no has probado tú mismo...
La creación de variables locales como objetos de estructuras y clases (sin new) ocurre en la pila.
Anteriormente describí cómofuncionan las matrices en MT5.
¡Qué mala suerte!
1 - A través de la creación de objetos. 2 - simplemente a través de una llamada a una función normal. El primer número es el tiempo en milisegundos, no prestes atención al segundo.
Es casi 10 veces más rápido (y a veces más de 10 veces). Qué cosa más triste... apilar... amontonar... ***cha
¿Por qué no prestar atención? Déjame adivinar: ¿INT_MAX realizó una vez una acción a través de la creación de un objeto temporal, y luego la misma acción a través de una llamada a una función?
Bueno, es un resultado esperado, teniendo en cuenta que todavía estamos bailando alrededor de la creación de la clase en el tiempo de ejecución (todavía debemos obtener este mango que parece un índice en algún contenedor).
PS. ¿Dónde está el código fuente de la repetición?
PPS. ¿Está seguro de que la función fue llamada? De todos modos, el optimizador está en este código también, no el hecho de que habrá una llamada de función en tiempo de ejecución:
El hecho de que UB en mql está allí - demuestra este código:
Que haya UB en mql prueba este código:
Usted ha envuelto hábilmente el compilador alrededor de su dedo:
- rama falsa se lanza porque no hay ruptura del bucle while(1).
- se devuelve true porque las operaciones se realizan en las variables locales sin ninguna interacción con el "mundo exterior" y la ejecución de este código también se tira.
Has envuelto inteligentemente al compilador alrededor de tu dedo:
- la rama falsa es lanzada porque no hay ruptura del bucle while(1).
- se devuelve true porque las operaciones se realizan en las variables locales sin ninguna interacción con el "mundo exterior" y la ejecución de este código también se tira.
No soy yo, es uno de los ejemplos de Internet. Es uno y el mismo de los pluses.
¿Por qué no prestar atención? Déjame adivinar: ¿INT_MAX realizó una vez una acción mediante la creación de un objeto temporal y luego la misma acción mediante la llamada a una función?
En definitiva, se trata de un resultado esperado, teniendo en cuenta que todavía estamos bailando alrededor de la creación de la clase en la aleatorización (deberíamos obtener este manejador que parece un índice en algún contenedor).
PS. ¿Dónde está el código fuente de la repetición?
PPS. ¿Está seguro de que la función fue llamada? De todos modos, el optimizador está en este código también, no el hecho de que habrá una llamada de función en tiempo de ejecución:
El hecho de que UB esté en mql prueba este código:
Te equivocas. No tienes que adivinar aquí, sólo recuerda que ayer, en caso de problemas de memoria, puedes buscar entre las citas para ver de qué trata la discusión. ¿Por qué el resultado se ha convertido de repente en algo esperado, si antes afirmabas lo contrario?
Sí, estoy seguro de que la función fue llamada. ¿Y a todos les gusta soñar que soy un idiota? ¿Por qué la pregunta es sólo sobre la función, y tal vez el objeto no fue creado tampoco? ¿O estás tan seguro de saber cómo funcionan todos los compiladores?
Me puedes explicar de qué va, porque soy un poco tonto, lo he leído tres veces - pero sigo sin entenderlo...
Mire las citas y vea de qué estamos hablando. Lo que he citado, y en respuesta a lo que estaba recibiendo esta respuesta de la cita.
Como a Dimitri le daba vergüenza publicar su código, he tenido que hacer yo mismo 15 minutos de pruebas.
Uy. Con operaciones idénticas, la diferencia es sólo del 30%.
La diferencia en tiempo de ejecución persiste incluso sin todo este lío con las variables y campos estáticos. Es la diferencia en microsegundos, no el porcentaje.
Conclusión: El coste de crear un objeto temporal en la pila es lo suficientemente pequeño en mi ordenador, que no es el más rápido, como para ser de unos 30-40 ns/pc (nanosegundo), por lo que debería prestarle atención en la mayoría de los casos.
PS. Y pensaba mal de los desarrolladores, pero no, simplemente no hay que tomar la palabra a la gente y comprobarla)))
Como a Dimitri le daba vergüenza publicar su código, he tenido que hacer yo mismo 15 minutos de pruebas.
Uy. Con operaciones idénticas, la diferencia es sólo del 30%.
La diferencia en tiempo de ejecución persiste incluso sin todo este lío con las variables y campos estáticos. Es la diferencia en microsegundos, no el porcentaje.
Conclusión: El coste de crear un objeto temporal en la pila es lo suficientemente pequeño en mi ordenador, que no es el más rápido, como para ser de unos 30-40 ns/pc (nanosegundo), por lo que debería prestarle atención en la mayoría de los casos.
PS. Y pensaba mal de los desarrolladores, pero no, simplemente no se toma la palabra de la gente y se comprueba)))
Y aún más hacer todo tipo de cálculos diferentes en el interior, la diferencia será aún menor. De todos modos, esta prueba difícilmente puede llamarse una prueba de funcionalidad idéntica.
Además, las pruebas en sí no son idénticas.