Comme d´habitude, j´ai un gros probleme ^^

Mon jeu a ( lentement) avancé et j´en suis là :

http://www.rafb.net/paste/results/2Nh5D840.html

Petite explication sur le programme.
En fait, il s´agit de la tete du serpent qui avance, et sa position est contenue dans le
SDL_Rect " pos[0]"
" max" est le nombre de carrés que contient le serpent, initialement 1, cad la tete
le reste importe peu...

La fonction de mouvement :
je prend le dernier membre du serpent ( max-1 car les tableaux commencent a 0) et je le fais prendre la place precedente. Puis, l´element precedent ( grace a i--) subit la meme operation etc...

Mon probleme :
A chaque fois que j´attrape le carré a attraper, mon serpent ne s´agrandit pas et je sais pas pourquoi.

• • Espere un reponse car il est bloqué su ce probleme depuis...3 bonnes heures**

nulissimo ->

Tu as mis :

max = max++;

Or l´opérateur ++ placé après une variable agit en post-incrémentation...Que veut dire cet étrange mot ? Ca veut dire que la fonction incrémente masi retourne la valeur avant incrémentation.

Ce qui nous donne dans ton cas qu´on incrémente max, mais qu´on retourne max avant incrémentation, et qu´on affecte cette valeur à max ! donc max ne change pas

Tu peux utiliser la préincrémentation :

max = ++max;

Mais là encore, c´est plutôt idiot puisque tu affectes la valeur de max à max lui-même

Il suffit juste de mettre l´opérateur ++ :

++max; / / Ou max++; mais il crée une copie locale

ne me prend pas pour le crétin de la terre , j´ai déja mis stdlib et ultoa ne marche toujours pas . .. je te dis que c´et dev-c++ qui doit pas le supporter , comme conio.h , et je me demandais si y´avait pas une manip à faire pour corriger ça !

dorian: conio.h est deprecié. en effet il ne fonctionne que sur certain compilateur et les fonction qu´il propose ne sont pas des fonction de la libC.

Sinon j´ai pas bien compris ce que tu veux faire, mais sprintf ne ferait il pas l´affaire ?

Ptitval: a propos des perateur de pre/post incrementation.
Il est surtout important que le lecteur prenne de bonnes habitudes de programmations. qu´il écrive un code clair et uniforme.
tu risques donc de le perdre en mettant des ++i; et des i++; il finira probablement par faire la confusion, mieux vaut rester simple je pense.

dynoplasma: pour ton truc, c´est bine un Up_event qu´il faut utiliser ca doit marcher tout pareil qu´un down

nullissimo: fais attention ton max pourrait aller au dessus de 50 ( qui est la tailel de ton tableau).
deplus tu stocke tes coordonnes 2D dans un SDL_Rect qui peut en contenir 4, peut etre devait tu ecrire une structure...
ta fonction attrape ne te laisse que 14*1à = 140 positions possible pour ton element a attraper, c´est dommage etant donné la taille du terrain.
pourquoi n´utilise tu pas rand pour faire ta generation aléatoire ?
de plus comme te dit ptitval: max = max++;
c´est assez bizarre comme expression, tu voulais ecrire max++ je penses.
if ( mort(max)==1)//si l´on reste en vie
ce n´est pas plutot mort(0) ? a priori, c´est 0 la tete non ?

ptival > je pense que tu as raison sur les itérateurs ++I au lieu de I++

Apres, l´idéal ce serait de faire un test de perfs pour voir qu´il est vraiment plus rapide ( je le ferai plus tard)
A mon avis, tu pourras mesurer les écarts en parcourant un bon million d´éléments

surtout qu´il n´y a pas de copi a mon avis, c´est un passage par reference. donc au final tu économise un passage de pointeur.

Effective C++ est un bon bouquin pour les developeurs C++ avancés,

J´ai fait un test avec 1 million d´éléments, je n´ai pas vu de différence fondamentale.
Du coup j´ai lancé un test sur 10 millions, mais ça s´est mis a swapper mortel
J´ai mis ma machine par terre, lol !
Alors j´ai lancé sur 5 millions, je n´ai pas vu non plus une différence fondamentale. Il est vrai que j´admet ne pas connaitre le mécanisme exact. Cependant, comme dit Godrik, c´est surement un appel par référence, ce qui expliquerait cela... A voir

bon je viens de verifier sur msdn. Je ne sais pas comment c´est fait dans les itérateur, mais la norme C++ dit: que la difference entre la fonction de pré-incrémentation et de post incrémentation est le parametre in qui est passe en post incrementation ainsi:
Toto& operator++(); / / Prefix increment operator.
Toto& operator++(int); / / Postfix increment operator.

pourrait etre les prototypes de fonction de pre et post incrementation.
Autant dire qu´un int sur la pile... on en pas pres de voir la difference!

moi je travaill actuellement sur l´API Windows et je veux convertir WORD / DWORD / DWORD_PTR / LPVOID et CHAR .

Qui peux m´expliquer comment ça marche sprintf ?

• en* et pas *et*

La MSDN est ton amie
http://search.microsoft.com/search/results.aspx?qu=sprintf&View=msdn&st=b&c=0&s=1&swc=0

JYY ->

LGV me faisait aussi part d´évaluer la fin de la liste avant le for, et de mettre Iterator ! = Truc_évalué, afin de ne pas évaluer la fin de la liste à chaque itération.

Evidemment, il faut faire attention dans ce cas à ne pas toucher à la liste lors du parcours, sinon le end pourrait être faussé...Donc pour le tuto mieux vaut donner un code sûr ( au cas où ils essayent de modifier la liste)

Dorian ->

Du calme, je ne te prends pas pour un imbécile, mais la première chose à laquelle je pense lorsqu´il ya un undeclared identifier c´est ça...Je ne connais pas ton niveau, et certains débutants oublient les #includes ( et pas que des débutants cf. moi )

Je me suis intéressé à ton problème et voilà ce à quoi je suis arrivé :

J´ai ouvert stdlib.h.
J´ai cherché ultoa pour voir s´il était vraiment pas déclaré.
Je tombe sur cette ligne :

_CRTIMP char* __cdecl _ultoa(unsigned long, char*, int);

Comme tu peux le voir, elle est déclarée précédée d´un ´_´

Donc si tu mets _ultoa dans ton appel ça marche

De plus pour éviter de te faire chier, tu peux balancer un :

1. ifndef ultoa
2. ifdef _ultoa
3. define ultoa _ultoa
4. endif
5. endif

( Il me semble)

perso je n´ai pas ultoa sur mon linux ( mais il est installé bizzare donc bon...)

perso je ferai un sprintf(buffer, " %d", mon_dword);
mais il n´y a pas de verification de la taille du buffer.

il n´y PAS d´int sur la pile lors d´une post-operation ; c´est une convention adoptee pour que le compilo sache lequel on surcharge, mais ce n´est pas DANS la version compilee.

une post-operation FAIT une copie de l´objet sur lequel elle s´applique ; selon l´objet, ca peut etre ou ne pas etre couteux. Un ++Object sera toujours aussi rapide sinon plus ( selon les cas), qu´un Object++

( tu parlais de Effective C++, ces petits details sont explicites dans More Effective C++)

et pourquoi elle fais ca ?

tu ne peux pas le definir en toto& operator++(int); ?

le fait est qu´un post++ dans une expression doit retenir la valeur en cours de l´objet, evaluer l´expression, et ensuite seulement retourne l´evaluation de l´operateur sur l´ancienne valeur

( ce que je veux dire, c´est que la copie intervient a un AUTRE niveau, dans l´evaluateur d´expression du compilo, qui generera la code pour la copie)

donc tu me dit que
int t;
int a;
t=a++;
ce n´est pas equivalent a
t=a;
++a;
?

si bien sur le resultat est le meme, conceptuellement c´est effectivement different. Mais il faut voir que la ton exemple utilises un type primitif, ce que le compilo va s´empecher de transformer a la compil durant l´optim.
Maintenant si tu veux ca avec des objets dont 1) la copie est couteuse ( i.e. un copy ctor qui duplique des grandes zones de memoire) 2) un operateur pre/post surcharge, alors non le resultat ne sera pas le meme
j´ai pas mon compilo sous la main, mais il suffit de faire generer le code asm pour s´en convaincre ( si j´y pense, je le ferai ce soir sur un exemple plus parlant)

toto a,b;
a = b++;
ne sera pas equivalent a:
a = b;
++b;
?
ca m´etonne fortement c´est extremement simple a derouler ( a condition que ++a et a++ soit implemtner pareil bien sur)