He encontrado un BUG, parece ser que los ints en memoria petan si hacemos una comparacion demasiado grande.
Tengo una variable global:
ScorePlayer1 = 0;
Si al principio de un proceso pongo esto:
IF (ScorePlayer1 > 999999999999)
ScorePlayer1 = 999999999999;
END
La variable global pasa a tener el siguiente valor:
ScorePlayer1 = -727379969
se te fue la mano con el numero... google y vas a encontrar el valor maximo de un int (con y sin signo)
demas esta decir que no es un bug del compilador... sino del programador.
todo por el contrario, es correcto que te de ese valor...
ya, pero un divlike tiene que controlar ese tipo de error
bennugd es mas orientado a C... ese valor, es el mismo valor que da C... asi que esta perfecto.
Pero lo que no entiendo es porque la condicion modifica el valor si esta no se verifica...
No hay int32 ? Que solución propones ?, porque quiero un score de ese tamaño...
el score de ese tamaño no lo vas a poder tener.
claro, porque 0 es mayor que -727379969
free, el int es int32... con 32bits no se puede hacer ese numero que pretendes, por eso tenes este problema.
primero te sugiero que no uses int, sino unsigned int, luego de eso, pongas el maximo en el valor maximo de un INT, pero diria que le saques 1 digito, porque sino nunca podras llegar al maximo ya que el numero da la vuelta.
usa google, pero te adelanto que solo podras usar de forma segura 9 digitos... otra opcion es pasar de los ints y hagas un array de digitos y te armas las funciones de suma (y resta si necesitas)
Me referia a int64 (que tonto soy).
int64 lo mismo que doubles, no existen en bennugd.
ahi voy yo, estaria bien que estuvieran ;D
eso ya lo sabemos todos desde hace mucho...
32Bits es aproximadamente 4.000.000.000, suponiendo enteros sin signos.
Lo de 64 bits ya se habló, que había que modificar muchísimas cosas del código interno (más bien todo, porque todo se basa en INT).
De todas formas, creo que la solución sería usar float ¿no? ¿no se diseñaron para representar tanto números pequeños como grandes? vale que no son tan precisos, que haría falta double, pero es lo que hay... o dividir el valor gigante en partes como dice Splinter, y usar multiplicaciones, divisiones y restos para acceder a una o a otra parte: por ejemplo, 37487 se puede representar como (37*1000) + (487*1) y sólo necesitas dos variables que contengan 37 y 487.
Como te ha dicho Spliter, la mejor solución es emplear el unsigned int.
p.d.: He estado un cuarto de hora riéndome, tio. Mira que no saber que las tipos de variable tienen límites... jajajajaja
Ya, pero en la practica te recuerdas siempre de los conceptos ?
Cuando declaras variables, intentas minimizar su uso y no crear variables inecesarias que sólo van ocupar memoria ?
Hay muchas cosas que uno sabe y que no implementa correctamente ni hace uso de ellas...
Pues yo si. De hecho, aunque es cierto que no suelo reutilizar muchas variables, suelo procurar que una gran parte de ellas sean locales. Para que sólo existan mientras se necesitan xD
Esque en clase me insistieron mucho en que un buen programador es el que maneja una buena metodología.
Me alegro por ti :D
En clase siempre dicen que hay que usar los tipos en función de los datos que se van a usar, y no me refiero a char si son letras o no, sino para datos con cifras pequeñas usar byte (o char), int para cifras grandes, float para decimales... ;D
Por eso uno termina por ver siempre los límites de las variables, aunque es rarísismo llegar al límite de un int (tendrías te trabajar con escenarios gigantescos y con incrementos de 100 para llegar). :D
Con Bennu, más que en aprovechar memoria, intento mantener los datos alineados de 4 en 4 bytes (poniendo por ejemplo, dos variables tipo BYTE y una WORD seguidas en la declaración), pero tampoco pasa nada por usar INT: salvo que vayas a usar arrays o listas enlazadas con tipos compuestos (que son los que más memoria consumen), prefiero usar INT porque luego dan menos problemas en los ports y, al parecer, són más rápidos de acceder.
Estamos hablando de máquinas con muchos MB de espacio. Hay que buscar equilibrio entre aprovechamiento y velocidad.