MQL5 El compilador no distingue entre una clase y un puntero a ella - página 6
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
El casting implícito de este puntero a un objeto
El nombre correcto es "desreferenciación implícita de punteros".
Apoyo la propuesta de no permitir, dejar la desreferenciación implícita sólo cuando se refiera a un miembro de la clase, como:
Aquí es lo contrario - un puntero es implícitamente fundido a un objeto (dereferenciado) y luego se le aplica operator=. fxsaber también lo mencionó ayer.
Aunque lógicamente no contradice las reglas de MQL (ya que llamar al operador= es igual a llamar a cualquier otro método del objeto), conduce a la ambigüedad en la comprensión de dicho código y a errores difíciles de encontrar. Y esto se refiere no sólo al operador=, sino también a == y !=. Quizás este tipo de casting debería prohibirse también para otros operadores, ya que en C++ se puede aplicar a los operadores: +-<>[].
La conclusión corta es esta: cuando se aplican operadores permitidos para punteros en C++ a un puntero, se prohíbe un casting implícito de este puntero a un objeto. En consecuencia, el ejemplo anterior tendría un error de compilación.
Sí, ya veo. Con estos sencillos ejemplos he querido demostrar a todos los dudosos que el puntero y el objeto son entidades diferentes y no hay que mezclarlas.
Y esta circunstancia requiere al menos un cierto estilo de escritura de código para no equivocarse y construir un código que compile e incluso pase la prueba pero que falle en condiciones reales, peor aún si fue escrito para la venta. No será una tarea fácil encontrar un punto de error en el código donde todo está tan "implícito".
Encontrar un lugar de error en un código donde todo está tan "implícito" será todo un reto.
Sería mejor que los desarrolladores dejaran las cosas como están. Si ahora empiezan a cambiarlo de nuevo, el lenguaje, un montón de programas dejan de compilar, o peor, dejan de funcionar como se espera, habrá un revuelo mundial.
Desde mi punto de vista, los auto-objetos en µl son un rudimento, sub-punteros con funciones limitadas (puntero constante con auto-borrado), y en su mayoría no necesitan ser utilizados en absoluto (excepto para el recolector de basura).
Sería mejor que los desarrolladores dejaran las cosas como están. Si ahora empiezan a cambiar de nuevo el lenguaje, un montón de programas dejan de compilar, o peor, dejan de funcionar como se espera, habrá un revuelo mundial.
Los cambios aquí son mínimos. Es sólo cuestión de añadir reglas de compilación a
para que no permita compilar la basura que ahora se considera buena.
Para que no te deje compilar el tipo de herejía que ahora se considera buena.
como A a = nuevo A? O lo que es exactamente ) es ahora utilizado por todo el mundo, por lo que no tiene ningún efecto
Pero si escribes A a, *b = a; obtienes un error en tiempo de ejecución, en este caso el compilador debe generar explícitamente la advertencia "probable uso de variable no inicializada 'b'" como hace con todos los demás tipos. Si no es un error de compilación en absoluto. Pero no por la asignación en sí, sino por usar una función sobrecargada en una variable no inicializada que provoca un error en tiempo de ejecución, claro. Esto es realmente un error y parece estar relacionado con una excesiva optimización del código.
Y en general no hay ninguna herejía en asignar auto a dino y viceversa, pueden ser características útiles.
Pero yo anularía por completo la copia implícita de objetos. Aunque es un estándar en C++. De hecho, es la razón de todos estos problemas.como A a = nuevo A? O qué exactamente )
Bueno, eso no hace falta decirlo. Hay una fuga de memoria aquí.
Pero en general no hay ninguna herejía en asignar auto a dino y viceversa, pueden ser características útiles.
Sí, déjalo estar. Pero explícito. Y se hará no por error mío, sino porque tengo que hacerlo.
Bueno, eso es un hecho. Hay una fuga de memoria aquí.
Bueno, esta fuga es puramente tu culpa. Si tienes un objeto a la izquierda, ¿por qué escribirías esa construcción?
Pero la situación inversa, cuando se asigna algo a un puntero y de repente es desreferenciado, es un error poco evidente.
Aquí todo está mezclado, tanto las moscas como las chuletas. Me refiero a la discusión del tema.
Si tienes un objeto a la izquierda, ¿por qué escribir esa construcción?
El factor humano. El compilador debería mantenerlo al mínimo.
El factor humano. El compilador debería mantenerlo al mínimo.