il n´y a pas de petite optimisation, sache le

lol

Bien le bon jour.

" il n´y a pas de petite optimisation, sache le"

Mouaip, mais le peu de performance que tu y gagne ne compense en rien la lisibité que tu y perds.

Personnellement je trouve que ce type d´optimisation frole le ridicule. Si tu veux de la rapidité, pourquoi ne pas tout faire en assembleur, la ton while fait a la main sera carrement plus performent que le truc ( infame) que ton compilateur t´as généré.

Pourquoi pas non plus mettre des varibles en globale ( ca fait free style en C++). Mettre des goto partout, et tout programmer en séquentiel....

Je suis un peu sarcastique... Il a été dit qu´optimiser le reste sera bien mieux est totalemnet vrai.

je suis entierement d´accord avec cooyote

j´apporterais cependant quelques precisions

// equivalent d´un for ( ;a!=0;a--) i=a
int a = 4, i = 0;
mov i , 0

test:
mov eax , 4
jnz fin
dec eax
mov i, eax
jmp test

:fin

// equivalent d´un while ( a--) i=a
int a = 4, i = 0;
mov i , 0

test:
mov eax , 4
jnz fin
dec eax
mov i, eax
jmp test

:fin

vous voyez ? c la meme chose ! ! cout de la boucle = 5 cycles d´horloge, celle du compilo 8 cycles
mais y a des registres a preserver ( push + pop = 8cycles a rajouter) + tout le reste a faire...donc ce n´est pas la peine de compter.

j´ai dit que son for allait booster son programme a mort? non

le for reste parfaitement lisible, bien plus qu´un while à mon gout car il a le merite de regroper la declaration, la condition et l´incrementation sur une ligne.. question de gout..
du reste ce sont les commentaires et un decoupage rigoureux en fonctions explicites qui rendent le programme lisible

ce qui importe ici c´est que remplacer un while par un for NE COUTE RIEN ni en temps de programmation ni en lisibilité ( pour peu qu´on soit un brin futé)
Si tu veux passer tout ton prog en asm ca va optimiser gravement mais bon courage.. c´est là toute la difference...
lorsque tu fais une boucle de traitement des evenements qui va tourner tout au long de ton prog mieux vaut alors utiliser un for qu´un while, c´est tout ce que je dis ici
comme tu as pu le voir, on gagne certes peu de temps mais je n´en ai perdu aucun a faire le remplacement

à bon entendeur...

Pryrates a raison, je vois pas pourquoi remplacer un while par un for fait perdre de la lisibilité. Si l´un des deux est plus rapide que l´autre, ne serait-ce qu´un tout petit peu, pourquoi s´en priver ?

Ah oui j´oubliais, j´ai perdu du temps tout de memde.. à aller faire un ssh sur trois becanes, sortir un emacs et compiler deux executables pourvous faire le test.. mais je suppose qu´on a pas a faire ca a chaque fois... j´ai perdu du temps aussi a repondre simplement a l´unique question qui etait posée puis a des hors sujets.. bref... le post precedent explique clairement ma pensée je crois que ce sera suffisant, sujet clos pour ma part

Au fait j´oubliais :

// equivalent d´un for ( ; a!=0;a--) i=a
int a = 4, i = 0;
mov i , 0

test:
mov eax , 4
jnz fin
dec eax
mov i, eax
jmp test

:fin

// equivalent d´un while ( a--) i=a
int a = 4, i = 0;
mov i , 0

test:
mov eax , 4
jnz fin
dec eax
mov i, eax
jmp test

:fin

ceci est une immondice absolue, ce code n´a aucun sens
déja les 2 premières lignes sont absurdes
mov eax , 4
jnz fin
l´instruction mov eax,4 ne peut pas mettre le zero flag a 1, donc ton code ne rentre jamais dans la boucle

rahh merde,

ca m´apprendra a essayer de détailler. mais je reste du meme avis que pryrate.

lol

ça ressemble plus à ça je pense

mov [i],0
mov ecx,4
test:
mov [i],ecx
dec ecx
jnz test

re-lol...
Au fait, j´ai une question pour les êtres pitoyables que vous êtes.
Il vaut mieux faire :
if(a && ! b)
ou bien
if(!a || b)
?

je me demande à qui tu t´adresses et qu´est-ce qui t´as fait croire que tu avais le droit de traiter d´êtres pitoyables la ou les personnes à qui tu t´adresses

Je dirais que tout dépend de laquelle de l´expression " a" ou de l´expression " b" a le plus de chance d´être fausse.

Si a est fausse :

- if(a && ! b) a est faux, on n´évaluera même pas b
=> eval(a)

- if(!a || b) on va faire le négatif de a, vrai, et donc ne pas évaluer b ( soit une opération NON de plus)
=> eval(a), NON

Si a est vraie

- if(a && ! b) évaluera a, trouvera vrai, évaluera b, en fera le négatif avant de faire enfin le ET
=> eval(a), eval(b), NON, ET

- if(!a || b) évaluera a, trouvera vrai, en fera le négatif, faux, et seulement là décidera d´évaluer b et enfin le OU
=> eval(a), NON, eval(b), OU

Ma conclusion : Garde tes " !" ( NON) pour la fin
Note : Un compilateur moderne avec ses options d´optimisation au maximum cassera peut-être ton expression pour l´ordonner dans l´ordre le plus efficace.

En me relisant, je me dis que de toute façon, la majorité des processeurs modernes disposent d´instructions JNZ et JZ, ce qui revient à inclure le NOT dans le test de saut...

J´hallucine, yen a qui trouve moyen de répondre en plus.
avant de répondre, tu aurais pu remarquer que ces deux instructions n´ont pas la même significations.
si tu prends a et b false,
a && ! b retourne false
! a || b retourne true

" En me relisant, je me dis que de toute façon, la majorité des processeurs modernes disposent d´instructions JNZ et JZ, ce qui revient à inclure le NOT dans le test de saut..."

les instructions jz et jnz existent depuis le 8086....