Errores, fallos, preguntas - página 2116
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
Los argumentos de la función no se calculan de derecha a izquierda
Resultado de la cadena (*) : 0:5041
Se espera en ambos casos: 0:0
Los argumentos de la función no se calculan de derecha a izquierda
Resultado de la cadena (*) : 0:5041
Era de esperar en ambos casos: 0:0
Esto no es un error. El compilador decide por sí mismo en qué orden calcular los argumentos.
Sólo hay que tenerlo en cuenta.
Esto no es un error. El compilador decide por sí mismo en qué orden calcular los argumentos.
El error es el siguiente: hasta hace poco, el orden estaba estrictamente definido por https://www.mql5.com/ru/forum/1111/page2040#comment_5858419(nótese la fecha y el extracto de la documentación: garantizado). Luego se cambió el orden tranquilamente (incluso en la documentación), y se pudo cambiar de forma civilizada: a través de inline https://www.mql5.com/ru/forum/1111/page2042#comment_5860752. Pero, ¿cómo debe saberlo el usuario? ¿Debe adivinarlo el usuario? ¿O antes de utilizar cualquier herramienta, mirar la documentación?
Errores de compilación y más
El error es el siguiente: hasta hace poco, el orden estaba estrictamente definido por https://www.mql5.com/ru/forum/1111/page2040#comment_5858419(nótese la fecha y el extracto de la documentación: garantizado). Luego se cambió el orden de forma discreta (incluso en la documentación), y fue posible cambiarlo de forma civilizada - a través de inline https://www.mql5.com/ru/forum/1111/page2042#comment_5860752. Pero, ¿cómo debe saberlo el usuario? ¿Debe adivinarlo el usuario? ¿O mirar la documentación antes de utilizar cualquier herramienta?
Simplemente no hay que escribir código que dependa del orden de cálculo de los argumentos.
En C++ el compilador tiene derecho a inlinear una función aunque no tenga la palabra clave inline.
En MQL no existe la palabra clave inline, el compilador integra las funciones sólo a su discreción.
El orden de los cálculos de derecha a izquierda se debe aparentemente a que los argumentos en este orden se colocan en la pila,
pero también pueden pasar por los registros.
Y en el caso de las funciones incorporadas, no existe el paso de argumentos como tal.
1. Simplemente no es necesario escribir código que dependa del orden en que se calculan los argumentos.
2. En C++, el compilador tiene derecho a inlinear una función aunque no tenga la palabra clave inline.
3. En MQL no existe la palabra clave inline, el compilador sólo incrusta las funciones a su discreción.
4. El orden de los cálculos de derecha a izquierda parece estar relacionado con el hecho de que los argumentos se colocan en la pila en este orden,
pero también se pueden pasar por los registros.
5. Y no hay paso de argumentos para las funciones incorporadas en absoluto.
1. ¿Por qué no debería ser así si el orden inverso está garantizado en la documentación y el código es más sencillo y claro en este caso? También podríamos negar el uso de las prioridades de la operación 5 + (2*3) y exigir que se pongan paréntesis (5 + (2*3)) en todas partes - en caso de que se cambie repentinamente
2. El compilador de C++ impone ciertos requisitos a las funciones incrustadas, lo que descarta esta situación https://www.mql5.com/ru/forum/1111/page2136#comment_6454818.
3. así es como se propuso que se introdujera
4. En los registros (a diferencia de la pila), los argumentos pueden colocarse en cualquier orden, incluso en el orden inverso
5. No es el orden de paso lo que importa, sino el orden de cálculo de los argumentos, y éste es el orden de cualquier función con más de un argumento. Y C++ lo tiene en cuenta antes de hacer (o no hacer) una función inline (ver punto 2)
1. Por qué no, si el orden inverso está garantizado en la documentación y el código es más sencillo y claro. También podríamos negar el uso de 5 + (2*3 ) y exigir poner paréntesis (5 + (2*3)) en todas partes - en caso de que se cambie repentinamente
2. El compilador de C++ impone ciertos requisitos a las funciones incrustadas, lo que descarta esta situación https://www.mql5.com/ru/forum/1111/page2136#comment_6454818.
3. así es como se propuso que se introdujera
4. En los registros (a diferencia de la pila), los argumentos pueden colocarse en cualquier orden, incluso en el orden inverso
5. No es el orden de paso lo que importa, sino el orden de cálculo de los argumentos, y esto es así para cualquier función con más de un argumento. Y C++ lo tiene en cuenta antes de hacer (o no hacer) una función inline (ver punto 2)
3. No sé qué se consigue con eso. ¿Quiere prohibir que el compilador incruste funciones sin especificar explícitamente inline?
2. No sé a qué te refieres.
4. Sólo estaba sugiriendo con qué estaba relacionada esa orden y su cancelación. No creo que se haya hecho por casualidad y siempre será así a partir de ahora. No hay nada terrible en ello.
5. Se equivoca. En C++, el orden de cálculo de los argumentos no está definido.
1. Llevo muchos años escribiendo en C++ y nunca me ha parecido un problema.
3. No sé para qué te servirá esto. ¿Quiere evitar que el compilador incruste funciones sin especificar explícitamente inline?
4. Me limité a sugerir de qué se trataba esta orden y su cancelación. No creo que se haya hecho por accidente y siempre será así. No hay nada horrible en ello.
5. Se equivoca. En C++, el orden de cálculo de los argumentos es indefinido.
3. Estaba sugiriendo que no se debería permitir al compilador cambiar el orden de cálculo de los argumentos para las funciones sin inlines.
5. El orden de cálculo lo define la implementación (el compilador) y es bastante concreto (de derecha a izquierda o de izquierda a derecha), y aquí, por ejemplo:
no está claro qué orden es 2-1-3 o 2-3-1 o lo que sea.
Resultado: 5041:0:5041.
Se espera: 0:0:5041 de izquierda a derecha o
5041:0:0 de derecha a izquierda
no está claro qué orden es 2-1-3 o 2-3-1 o lo que sea
No entiendo por qué escribir un código que es obviamente ambiguo.
No entiendo por qué escribir un código que es obviamente ambiguo.
Una pregunta similar para usted https://www.mql5.com/ru/forum/1111/page2037#comment_5842347