La nueva sintaxis de MQL4 - página 3

Nuevo comentario
 

Tengo una pregunta sobre los tipos de variables, int, uint, char, short ushort etc. El nuevo compilador advierte sobre la posible pérdida de datos debido a la conversión de tipos, por lo que es la mejor práctica para;

a) utilizar el que mejor se adapte a los requisitos de la variable o,

b) evitar la conversión entre tipos y, por tanto, utilizar int para todo. (bueno, todo lo que no necesite un punto flotante)

 
SDC:

Tengo una pregunta sobre los tipos de variables, int, uint, char, short ushort etc, ¿es la mejor práctica para;

a) utilizar el que mejor se adapte a los requisitos de la variable o

b) evitar la conversión entre tipos y, por tanto, utilizar int para todo. (bueno, todo lo que no necesite un punto flotante)

Si necesitas un unsigned long un int no te servirá... usa el tipo correcto y una conversión de tipo explícita. OMI
 

¿Por conversión explícita de tipos se refiere a hacer la conversión antes de cualquier cálculo entre tipos diferentes?

 
RaptorUK:
Si necesitas un unsigned long un int no te servirá... usa el tipo correcto y una conversión de tipo explícita. OMI

De acuerdo.
 
SDC:

¿Por conversión explícita de tipos se refiere a hacer la conversión antes de cualquier cálculo entre tipos diferentes?

Véase aquí : https://www.mql5.com/en/docs/basis/types/casting
 

Buen artículo gracias angevoyageur lo leeré bien cuando llegue a casa del trabajo.

 
SDC:

¿Por conversión explícita de tipos te refieres a hacer la conversión antes de cualquier cálculo entre diferentes tipos?

No, me refiero a que puedes convertir un ulong a un int así....

ulong VariableUlong;

int VariableInt;

VariableUlong = 100;

VariableInt = (int) VariableUlong;   // explicit typecasting . . .  
 

Vale, sí, eso es lo que pensé que querías decir.

Excepto que realmente no estaba preguntando sobre ulong. Rara vez, si es que alguna vez necesito trabajar con valores tan grandes que no pueden ser acomodados por un entero de 32 bits. Ni siquiera sé cómo decir el número que un entero de 64 bits puede contener lol ...

Probablemente debería haber sido más específico, no tuve tiempo esta mañana para escribir mi pregunta correctamente, pero ahora que estoy en casa lo haré.

En el viejo mql4 usábamos enteros para todo. Escribiríamos for(int i=0; i<100; i++) No necesitamos valores negativos, y no necesitamos un valor mayor que 100 así que podríamos usar una uchar para eso. ¿Significa esto que es lo que debemos hacer?

Cuando miro el código de otros programadores, muchos de ellos parecen usar tipos enteros de 32 bits en todos los casos. ¿Hay alguna razón válida para ello? ¿Qué saben ellos que yo aún no he descubierto? ¿Utilizar los tipos de variables más pequeños en un programa crea un dolor de cabeza de problemas de encasillamiento sin otra razón que un tamaño de archivo ligeramente menor? ¿O ahorra un montón de RAM? ¿Es seguro asumir que mientras el valor de un tipo pueda ser acomodado por otro tipo es correcto hacerlo? ¿El encasillamiento entre diferentes tipos utiliza mucha más CPU que utilizar el mismo tipo?

Actualización: He estado buscando esto y he leído esta respuesta a una pregunta similar en stackoverflow.com

"En cuanto al rendimiento, un int es más rápido en casi todos los casos. La CPU está diseñada para trabajar eficientemente con valores de 32 bits.

Los valores más cortos son complicados de tratar. Para leer un solo byte, por ejemplo, la CPU tiene que leer el bloque de 32 bits que lo contiene, y luego enmascarar los 24 bits superiores.

Para escribir un byte, tiene que leer el bloque de 32 bits de destino, sobrescribir los 8 bits inferiores con el valor del byte deseado y volver a escribir todo el bloque de 32 bits.

En cuanto al espacio, por supuesto, se ahorran algunos bytes utilizando tipos de datos más pequeños. Así que si estás construyendo una tabla con unos cuantos millones de filas, entonces puede valer la pena considerar tipos de datos más cortos. (Y lo mismo podría ser una buena razón para usar tipos de datos más pequeños en tu base de datos)

Y desde el punto de vista de la corrección, un int no se desborda fácilmente. ¿Qué pasa si crees que tu valor va a caber en un byte, y luego en algún momento en el futuro algún cambio de apariencia inofensiva en el código significa que se almacenan valores más grandes en él?

Estas son algunas de las razones por las que int debería ser tu tipo de datos por defecto para todos los datos integrales. Sólo usa byte si realmente quieres almacenar bytes de la máquina. Sólo usa shorts si estás tratando con un formato de archivo o protocolo o similar que realmente especifica valores enteros de 16 bits. Si sólo estás tratando con enteros en general, hazlos ints".

 
SDC:

Vale, sí, eso es lo que pensé que querías decir.

Excepto que realmente no estaba preguntando sobre ulong. Rara vez, si es que alguna vez necesito trabajar con valores tan grandes que no pueden ser acomodados por un entero de 32 bits. Ni siquiera sé cómo decir el número que un entero de 64 bits puede contener lol ...

Probablemente debería haber sido más específico, no tuve tiempo esta mañana para escribir mi pregunta correctamente, pero ahora estoy en casa lo haré.

En el viejo mql4 usábamos enteros para todo. Escribiríamos for(int i=0; i<100; i++) No necesitamos valores negativos, y no necesitamos un valor mayor que 100 así que podríamos usar una uchar para eso. ¿Significa esto que es lo que debemos hacer?

uchar - Unsigned Character, ¿por qué usar esto para un bucle? no tiene sentido para mí... usa un int. Estarás trabajando con ulongs, eso es lo que es un nuevo datetime . . . y cuando encasilles sin pensar en ello en el futuro serás advertido . . . lidia con la advertencia o ignórala. Pero no esperes lo mejor, haz lo que estás haciendo ahora, aprende y entiende

Lo que has publicado de stackoverflow me parece que tiene sentido, creo que es un buen consejo.

 
SDC: ¿El encasillamiento entre diferentes tipos utiliza mucha más CPU que utilizar el mismo tipo?

Entre diferentes tamaños utiliza más CPU, no mucho más. Sólo instrucciones diferentes como las mencionadas fetch de 32 bits, isolate, operate, place, write, cuando se modifica el char en una estructura. Al igual que multiplicar por 0,5 utiliza ligeramente menos CPU que dividir por 2,0

Guardar 16 bits por elemento de array no tiene sentido en máquinas de GB, yo lo hice cuando implementé aplicación, base de datos, GUI (vt100) en 8 KB (sic.) Pasar a 64 bits por (para todo,) no tendrá sentido hasta que las plataformas de 128 bits sean un lugar común.

Con signo vs sin signo no hay diferencia. Es sólo una asignación, no se cambian los bits. La diferencia es el código que utiliza la variable. Por ejemplo, A[índice] hace Address(a) + índice * sizeof(a[0]) donde el más es una suma con o sin signo.

Para la claridad de la codificación, yo usaría uint para indexar arrays ya que A[-1] no tiene sentido pero entonces la cuenta atrás es problemática FOR(uint iA=n; iA >= 0; iA--){} iA>=0 es siempre verdadera.

Utilice int (o uint) a menos que deba hacerlo por otras razones.
123456
Nuevo comentario