Décidement, g du mal ac le C... - Page 1

Cette fois, soit je suis devenu une tache en maths, soit y'a un problème qq part...

Voilà l'objet du délit : (tbl_anm[var_for]+((var_mul*aaaa)/100));

J'ai testé toutes les valeurs avant le calcul, et :
tbl_anm[var_for] = 159
var_mul= 50
aaaa= -159

Donc logiquement ça fait :
159+((50*(-159)/100))
159-79
80

Or ça ne fait pas du tout 80 à la fin du calcul mais qq chose dans les 700

Autre question : qu'existe-t-il comme routine d'affichage de rectangle plein ultra-rapide ?

Hé hé encore un problème de compatibilité de types
On peut avoir les déclarations de tes trois variables ?

G pris un screenshot, avec les lignes en cause :

temp=((mul*(anm[x+5]-anm[x]))/100);
printf_xy(20,40+10*(x-num-3),"(%d * (%d - %d))/100 = %d ",mul,anm[x+5],anm[x],temp,A_NORMAL);

alors les types :

tbl_anm (renommé en anm) : unsigned int *
var_for (renommé en x) : unsigned int
var_mul (renommé en mul) : unsigned int

tu dis utiliser des unsigned int...
or, tu affiche tout en considérant que c'est des int signed.

(%d => signed int)

il faudrait mettre %du je penses pr unsigned int

ah c pas considéré pareil ?
enfin c pas l'affichage qui est en cause, puisque ces valeurs servent après pr dessiner une ligne. Or dessiner une ligne à (0,0)(700,700) avec DrawLine, ça marche pas très bien

Je pense que l'affichage est correct, par contre la valeur l'est beaucoup moins

unsigne int et signed int ne sont pas considéré pareil !!!
(utilises short plutôt que int, d'ailleurs, si tu veux des vars codées sur 2 octets... partce que int est vague)

le bit de poids fort a une signification différente si c signed ou unsigned...

si c unsigned, le bit de poids fort compte ds le nombre
sinon, il indique le signe (en gros, technique du complément à deux)

V essayer short, même si j'ai rien comprit à ton explication
(dans ton tuto, y'a marqué que int et short c la même chose...)

Alors c'est simple : c'est à cause de la division et de la multiplication : il faut savoir que ces deux opérations traitent les données différemment suivant qu'elles soient signées ou non. Tu as déclaré tes variables comme non-signées. Or, la première opération effectuée dans ton code (soustraction) renvoie un résultat négatif (signé) !

Le compilateur, lui, il va demander au processeur de diviser et multiplier en considérant les données comme non-signées puisque les variables sont non-signées... Comme en fait ce qu'il divise et multiplie est négatif (à cause de la première opération), le résultat est faux !

Deux solutions :
- le transtypage : temp= ((mul * (int)(anm[x+5] - anm[x])) / 100)
- déclarer les variables comme étant signées : int var_for, var_mul, *tbl_anm

[edit]Edité par Thibaut le 20-03-2002 à 18:37:13[/edit]

Bon, enfin, ça doit être question de cast...
les unsigned doivent être transformés en sgned, ou le contraire...

temp=((mul*(anm[x+5]-anm[x]))/100);

temp, c quel type ?
mul : Unsigned int
anm = unsigned int
x : unsigned int

sous TIGCC, avec les options par défaut, int == short
mais ce n'est pas le cas sous d'autres compilo...

même, sous TIGCC, il est possible que int == long si on met l'option -mforceint ou -mlong, ou un truc comme ça....
=> mettre short assure une certains sécurité.

la norme ANSI dit uniquement ceci :
char <= short <= int <= long
(idem pr unsigned)

Mmm... V essayer ça tout de suite

Heu je pense utiliser le transcryptage, puisque *tbl_anm est nécéssairement unsigned dans un autre endroit du prog...

Verdict dans 5 minutes

Verdict : Thibaut tu est génial

Merci à vous 2 !!!

Nan je suis pas génial, c'est juste que je connais un peu le fonctionnement des compilateurs (Azur rulleeeZZ), donc pour moi ce genre de problèmes est parfaitement évident


On ne dit pas "transcryptage" mais "transtypage"

Bob> de rien
(même si j'ai pas fait grand chose )

sinon, pr le post 11, il faut rajouter sizeof(TYPE) à chaque fois... (en remplaçant TYPE par char, int, ...)

Thibaut > c noté
Squale > si, tu m'as apprit qq chose sur les int/short, et puis au moins tu as essayé, et c sympa

oué, g essayé... dsl de pas avoir fait mieux.

ce quelque chose entre int et short ne te servira pas souvent (voire même jamais) sous TIGCC, mais il peut te servir si tu codes sur une autre machine.
Par exemple, sur les PC 32 bits (le tien en fait partie), les ints sont généralement de 32 bits => 2x plus que sous TIGCC
sous MSVisualC++6.0, les int correspondent à des long. (je crois bien !)

en fait, int correspond généralement à la taille d'un entier sur la machine de destination.
Sur un PIII, qui est un processeur 32 bits, ça sera 32 boits
sur un M68k, qui est un proc 16 bits (32 en interne, mais proc 16 bits qd même), ça sera 16 bits
DE FACON STANDARD... après, les standard se contournent

Voilà l'effet, vous en conviendrez très impressionant, que votre aide m'a permit de réaliser :



Ça vous en bouche un coin hein ? Pas la peine de le nier je le lis sur vos visages

Est-ce qu'il existe une routine d'affichage de rectangle plein + rapide que celle du TiOS ? (en noir et blanc)

Je ne sais pas

J'en ai une hyper-rapide qui traîne quelque part dans le bodel des feuilles de mon classeur de physique, au verso d'un polycopié de cours. J'avais programmé ça (en ASM) au début de l'année, un jour ou je me faisais chier. Si j'arrive à retrouver le truc dans mon bordel innomable...

Bob64> fait la avec la routine de HLine qu'avait donné jackiechan[...] dans un topic pr lolo ...

Thibaut > on a la Bible des compilateurs dans notre bibliothèque

nEUrOne > Si je fais un rectangle moi même ac cette routine ça ira + vite que le DrawClipRect du TiOS ???

Miles :

Miles > la bible des compilateurs, il est pas nommé le "dragon" ? (Alfred aho, Ravi Sethi, Jeffrey Ullman)
si c'est ça je ne pense pas que thibaut puisse en tirer grand chose !