Discussion :

[tnarol]

Salut,

Je me pose très souvent la question suivante.

Est ce que l'exemple de code ci dessous s'exécute plus vite que l'autre exemple qui le suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
char temp[256];
int i = 0;
for (i=0; i<1000; i++)
{
sprintf(temp, "%d", i);
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
int i = 0;
for (i=0; i<1000; i++)
{
char temp[256];
sprintf(temp, "%d", i);
}

[Médinoc]

En théorie sans optimisation, il est fort possible que oui.
En pratique, tout compilateur potable optimise le truc...

[tnarol]

En théorie sans optimisation, il est fort possible que oui.
En pratique, tout compilateur potable optimise le truc...

Le compilo de Visual C++ par exemple ?
Et sinon dans l'absolu, pour des cas un peu plus complexes, vaut-il mieux écrire la première ou la deuxième version ? La deuxième se voudrait respecter une règle de codage qui préconise une déclaration des variables locales au plus près de leur utilisation...

[Médinoc]

Je suis à 100% pour la seconde.
La seule raison qui pourrait me faire écrire la première, c'est si j'avais besoin du contenu du buffer une fois la boucle terminée, ou d'une itération à l'autre.

[souviron34]

Je vais faire hurler les puristes, mais bien que ne respectant pas cette règle, je suis 100% pour la première

En effet, je considère que la déclaration de variables limitée au plus proche de l'instruction est lisible et compréhensible instantanément lorsqu'il s'agit d'un petit morceau de code du style debug ou autre, mais je suis résolument contre en ce qui concerne des routines assez grandes, particulièrement pour des raisons de maintenance et de portage.

En effet, lorsqu'on reprend ou maintient de gros codes, on a envie d'avoir en un seul coup d'oeil ce que fait la routine et ce dont elle se sert. Il est très pénible d'avoir à explorer ligne à ligne pour connaître toutes les variables à utiliser. Et c'est d'autant plus vrai si on veut porter le code sous un autre langage.

Enfin, pour l'exemple cité, à l'intérieur d'une boucle, je considère que l'instruction de début (for) fait partie de l'ensemble, et non ce qui est contenu dans les accolades. Donc dans ce cas précis (comme lors d'un while) je ne considère pas les accolades comme limitant l'instruction, mais le "f" et la fin de l'accolade.


Mais ce n'est qu'un avis de praticien et non de théoricien

[Franck.H]

Enfin, pour l'exemple cité, à l'intérieur d'une boucle, je considère que l'instruction de début (for) fait partie de l'ensemble, et non ce qui est contenu dans les accolades. Donc dans ce cas précis (comme lors d'un while) je ne considère pas les accolades comme limitant l'instruction, mais le "f" et la fin de l'accolade.

Mais ce n'est qu'un avis de praticien et non de théoricien

Je suis du même avis, d'ailleurs je vois très bien et cela a toujours été le cas, une boucle for (comme while aussi) son expression et ses instruction comme un tout unique, comme on le ferais en assembleur par exemple

[tnarol]

Ok bien compris, merci à tous.