Iteration en langage C(ou C++)

[lavela]

bjr ,tt le monde ,on nous a dit d'ecrire un programme qui affiche les 50 premiers nbres paires de 3 facon suivantes:
-avec une boucle while (...) {...};
do {...} while(...);
for (...;...;...) {...};Merci d'anvance

[Joker62]

Jte fais la boucle for

for (int i=0; i<50; i++)
printf("Nombre %i : %i", i+1, 2*i);

[Dominique Lefebvre]

Jte fais la boucle for

for (int i=0; i<50; i++)
printf("Nombre %i : %i", i+1, 2*i);

j'efface, je dis des conneries! J'ai lu trop vite... ça marche

[Joker62]

J'ai quand même mélangé C et C++ beurk :D

[Dominique Lefebvre]

J'ai quand même mélangé C et C++ beurk

ouai le int dans la boucle, c'est pas beau... Et aussi, on ne manipule pas en principe les indices de boucle, à la limite pour les imprimer mais le 2*i n'est pas très beau non plus, mais bon...

[muse]

C'est pas tres compliqué.

avec for

int main ()

{
int i;
int j=2 //le nombre a afficher

for(i=0;i<50,i++)
{
printf("%d \n",j);
j=j+2;
}

return 0;

}

y'a des milion de maniere differente de faire...

[Flodelarab]

ouai le int dans la boucle, c'est pas beau... Et aussi, on ne manipule pas en principe les indices de boucle, à la limite pour les imprimer mais le 2*i n'est pas très beau non plus, mais bon...

Double carton jaune = carton rouge !

le int dans la boucle est bon car il permet de limiter la portée de la variable. Donc efficacité accrue.

Le 2*i n'est pas une modification de l'indice mais une utilisation de l'indice donc rien de mauvais.

ok?

[Dominique Lefebvre]

Double carton jaune = carton rouge !

le int dans la boucle est bon car il permet de limiter la portée de la variable. Donc efficacité accrue.

Le 2*i n'est pas une modification de l'indice mais une utilisation de l'indice donc rien de mauvais.

ok?

Eh mec, j'ai pas dis que ça ne marchait pas! Il faut lire avant de dire des conneries...
j'ai dis que c'était pas beau! Si tu passes un outil d'audit de code la dessus, ça te jette! Mais tu dois appartenir à cette nouvelle génération de programmeurs que je vois débarquer dans mon labo...

Mais ce que j'en dis, moi, tu sais...

[Flodelarab]

Tu trouves plus beau de déclarer une variable de façon globale et d'encombrer la mémoire pendant tout ton programme plutot que de limiter la durée de vie de ce compteur insignifiant à la bouclette ?????

[Patastronch]

Si tu fais du C++ utilises les librairies C++ et pas les librairies C.

"printf" est à banir, utilises "std::cout" à la place.

[Dominique Lefebvre]

Tu trouves plus beau de déclarer une variable de façon globale et d'encombrer la mémoire pendant tout ton programme plutot que de limiter la durée de vie de ce compteur insignifiant à la bouclette ?????

As-tu entendu parlé de lisibilité et de maintenabilité des codes?

Ce qui est tolérable (et encore, cela dénote de mauvaises habitudes!) dans un code de 10 lignes ne l'est pas dans un code de plusieurs centaines ou plusieurs milliers de lignes. C'est pour cela que les outils d'audit ne permettent pas ce genre d'écriture.

Pour ce qui est d'écrire des indices de boucle en variables globales, il est très rare, sauf dans les prog de 10 lignes, de trouver des boucles dans le main(), sauf peut être une ou deux lorsqu'il s'agit d'automates en mesure ou télécom. C'est là aussi contraire aux principes de structuration et de lisibilité du code.

Quant à l'optimisation, tu ferais mieux de la confier au compilateur (avec l'option qui va bien...). C'est son boulot, et il le fera bien mieux que toi! Ton boulot à toi, c'est d'écrire un code lisible, aéré, qu'on pourra comprendre dans 6 mois et qui sera facilement maintenable. Et qui fonctionne conformément à ses spécifications...

[Patastronch]

Au passage on ne pouvait pas déclarer de variable dans le for en C contrairement au C++. Et la raison est justement la lisibilité du code. Rien de pire que les codes en C ou tu vois 15 int déclaré juste pour les boucles ( plus les 15000 autres variables temporaires qui seront utiles que dans 1000 lignes de codes parcequ'on peut les déclarer que dans le bloc principale).

Quant a l'argument de laisser le compilateur oeuvrer pour les optimisations c 'est bien une réponse de physicien ca ! Si c'est vrai pour le java (qui est tres maladroit sur l'allocation de la memoire et sa libération) c'est atrocement faux en C/C++.

Quand tu lances un valgrind sur tes codes C/C++ il doit hurler non ?

Sinon dans le fond je suis d'accord avec ton argument de dire qu'il vaut mieu privilégier la clarté sur l'optimisation. C'est d'ailleur pour ca qu'on est passé a la programmation par objet. Ca n'apporte rien a part une structure élégante,claire et facilement adaptable (au contraire c'est meme legerement moins optimisé dans la plupart des cas). L'ennuie c 'est que la plupart des programmeur n'ont aucune notion de sémantique et ne savent pas programmer en objet, du coup ils font des trucs qui'n'ont aucun sens.

Et je suis également d'accord avec Flo, tant que ta variable d'incrémentation n'est utilisée qu'en lecture y a aucun probleme, sinon elle ne servirait à rien au passage ...