Errores, fallos, preguntas - página 2521

 

fxsaber:
Подскажите, как в C++  с этим? Задумался, использовать эту фишку в своем коде или нет. Если в C++ работает, буду использовать. Нет - вряд ли, т.к. могут отменить в следующих билдах.

b = a; 
a = b; // OK

La primera asignación sólo funciona en MQL. Y es una pena que funcione, ojalá supriman de una vez este malentendido. No hay problemas con el segundo.

 
Alexey Navoykov:

La primera asignación sólo funciona en MQL. Me gustaría que cancelaran de una vez este malentendido. No tengo problemas con el segundo.

Qué raro. Pensé que el primero debía funcionar y el segundo no.

 
fxsaber:

Qué raro. Pensé que el primero debía funcionar y el segundo no.

Bueno, aparentemente, los desarrolladores de MQL tampoco entienden la esencia de la asignación. Porque hace tiempo que les hablo de este problema, pero choca con un muro.

La esencia de la asignación es que al objeto se le asigna un objeto equivalente. Significa que el objeto derecho es primero fundido al tipo del objeto izquierdo implícitamente y sólo entonces tiene lugar la asignación (copia). Y en el primer caso tal fundición (A->B) es ciertamente imposible.En C++ habría un error, pero en MQL en cambio el objeto izquierdo es fundido al derecho y se ejecuta A::operator=(A&), reemplazando sólo parte del objeto b. ¿Es esto una asignación?

Imagina que estás asignando un int a un long, pero sólo se reemplazan los cuatro primeros bytes y el resto queda intacto. Aquí ocurre lo mismo.

 
Alexey Navoykov:

Imagínate que asignas un int a un long, pero sólo se sustituyen los cuatro primeros bytes y el resto queda intacto. Aquí ocurre lo mismo.

Así que es conveniente, supongo. En el contexto de las estructuras, por supuesto.

 
fxsaber:

Así que es conveniente, parece. En el contexto de las estructuras, por supuesto.

Puede guardar caracteres en una cadena, pero es una fuente de errores aleatorios y complica/distorsiona la comprensión del código. Como se ha dicho anteriormente, el signo de igualdad tiene un significado claro e inequívoco de que se cambiatodo el objeto. Por eso el operador no se utiliza como se pretende en este caso. Si se quiere ese comportamiento no estándar, se debe sobrecargar el operador para tales fines.

p.d. La única excepción es si la clase B no tiene campos propios, es decir, es exactamente igual a la clase A (totalmente equivalente a ella), entonces no hay razón para impedir esta asignación, aunque de todos modos no funciona en C++, pero en MQL se puede permitir.

 
Slava:

En el archivo opt, en el chunk donde se prescriben todos los parámetros de entrada, el valor de los parámetros optimizados (definidos a través de los campos size y offset) no contiene Value (como sin optimización), sino Start.

Sería lógico que el Valor estuviera allí.

 
Alexey Navoykov:

Pues bien, parece que los desarrolladores de MQL tampoco entienden bien la esencia de la asignación. Porque hace tiempo que les hablo de este problema, pero choca con un muro.

La esencia de la asignación es que al objeto se le asigna un objeto equivalente. Es decir, del mismo tipo.

La esencia de las operaciones para los tipos de usuario no está definida de antemano. Y sólo se define su orden, que en este caso consiste en llamar al operador= adecuado.

En MQL, a diferencia de C++ operator= se hereda, por lo que b = a; es equivalente a llamar a A::operator=(const A&);

En general, no hay ninguna contradicción. En el caso especial de la asignación de un objeto equivalente, existe cierta inconsistencia de la entidad, pero no más que eso

 
A100:

En MQL a diferencia de C++ operator= se hereda, por lo que b = a; es equivalente a llamar a b.operator=(const A&);

Pues sí, ese es el problema. Pero la diferencia de escritura no juega un papel en este caso. En C++ no compilará en ambos casos.

En general, no hay ninguna contradicción. En el caso especial de la asignación de un objeto equivalente, existe cierta inconsistencia de entidades

Habrá una contradicción con C++ al menos. Si compila, significa que el operando de la derecha está implícitamente fundido al de la izquierda y luego se produce una sustitución completa del objeto, como lógicamente debería funcionar. He puesto un ejemplo con int->long. Y la sustitución de parte del interior de un objeto no es una asignación. Así que hay tanto contradicción como inconsistencia.

p.d. Aunque el operador B::operator=(A&) también puede ser sobrecargado, pero supongo que un programador sensato reemplazaría allí el objeto B completamente en lugar de parcialmente, pues esta es la esencia de la asignación.

Si se quiere una ortografía concisa, se podría hacer algún otro operador para ello: &= o |= por ejemplo. Por lo menos no se usan comúnmente, así que no hay confusión.

 
Alexey Navoykov:

..........

Una contradicción sería al menos con C++. ......

..........

¿Qué te hace pensar que MQL debe ser totalmente equivalente a C++?

C-like no significa equivalente.

MQL está desarrollado para tareas definidas y no está obligado a copiar completamente el lenguaje en el que se basó.

¿Quieres dejar de indignarte?

Pero en Pascal se puede .........

En Assembler puede ir a .....

Y en Java ....

Y en BASIC ....

¿Practican aquí la comparación de idiomas?

=======

P.D. No eres sólo tú...

 
Сергей Таболин:

¿Qué te hace pensar que MQL debe ser totalmente compatible con C++?

...

¿Practican aquí la comparación de idiomas?

Respondía a una frase concreta. Cálmate. Toma un poco de valeriana y vete a la cama. No es bueno que te preocupes. ...Algunos se calientan con la palabra "C++".