Discussion :

[Gui13]

Bonjour à tous,

Voilà je suis confronté à un petit problème: dans les blocs d'accolades, on est d'accord que les variables créées sont temporaires (elles disparaissent à la fin du bloc)?

Voici 2 codes très simples qui me chiffonnent:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#include <stdio.h>
#include <iostream>
 
using namespace std;
 
int ajoute(int & d){
  int k = d+1;
  if(k == 3){
    int e = 3;
    cout << d << endl;
  }
  cout << d << endl;
}
 
int main(){
  int d = 2;
  ajoute(d);
  return 0;
}

Me donne la sortie suivante (normal, j'ai envie de dire):

Code :

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

1
2
3
 
2
2

Maintenant celui-ci:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#include <stdio.h>
#include <iostream>
 
using namespace std;
 
int ajoute(int & d){
  int k = d+1;
  if(k == 3){
    int d = 3; //cette variable a le même nom que l'argument que la fonction a recu!
    cout << d << endl;
  }
  cout << d << endl;
}
 
int main(){
  int d = 2;
  ajoute(d);
  return 0;
}

Me donne la sortie :

Code :

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

1
2
3
2

Le probleme, c'est donc que dans ce bloc "if{...]", je ne peux plus avoir accès à l'argument de la fonction ajoute(). Et puis même, comment le compilateur fait pour ne pas s'emmeler les pinceaux?

Bizarre, bizarre, vous avez une explication?

[Médinoc]

Le premier cout est dans le bloc interne, il prend donc la variable d du bloc interne. C'est aussi simple que ça: Le compilo utilise une pile pour les noms de variables (typiquement, une pile de "tables des symboles").

[loicounet]

je ne vois pas trop le problème:
déjà pour des arguments de fonction, il faut éviter à tout prix des lettres comme "d"...préférer des nom plus signification genre "valeur"
genre si tu utilise un argument appelé "i", et que tu utilise des boucles...oulalala....

ensuite pour le coup du if, je crois qu'à l'intérieur d'accolades, ca utilise la pile...seule la variable locale est vue dans le if, une fois sorti du if cette valeur disparait et l'argument de la fonction réapparait

enfin évite de faire ce type de double déclaration...si tu fais ça dans un programme de 5000lignes de code et que tu dois debugger 3mois après ça peut être délicat

[ram-0000]

En montant le niveau de warning du compilateur et suivant les compilateurs, il n'est pas possible d'avoir un message qui permette de détecter ce genre de situation.

Il me semble me rappeler que sur le compilateur HP-UX, il y avait des messages de ce genre "Warning symbol 'toto' is overriding another symbol".

En tout cas, le compilateur de Visual Studio 2005 SP1 ne signale rien, je viens de tester.

[Feriaman]

Salut,

C'est très bien de se poser ce genre question, cela veut dire que tu t'intéresse au fonctionnement du langage. Félicitations, c'est une bonne approche.

Quand tu dis :

Le probleme, c'est donc que dans ce bloc "if{...]", je ne peux plus avoir accès à l'argument de la fonction ajoute().

C'est une bonne analyse, cela veut dire qu'en utilisant le même nom de variable pour représenter deux choses différentes, tu te prives de l'une des deux.

Et puis même, comment le compilateur fait pour ne pas s'emmeler les pinceaux?

Ne t'inquiètes pas les compilateurs sont VRAIMENT très forts. A un point que l'on a du mal à concevoir. Si tu te penches un jour sur les problèmes d'optimisation de code par le compilateur, tu verras à quel point ils peuvent "penser" à des choses qui sont loin au delà de notre intelligence.

Donc pas de soucis, ils ne s'emméleront pas les pinceaux.

Par, contre, nous si.

Et comme nous ne sommes pas aussi fort qu'eux, on fait tout pour se simplifier la tâche. En particulier, on essaie d'éviter ce dont tu parle, à savoir nommer deux variables de la même façon.

En général, on essaie d'utiliser des noms de variables clairs et lisibles, pareil pour les noms de fonction

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#include <iostream>
 
using namespace std;
 
int afficheEntierPlus1PuisEntier(int& entierAAfficher){
  int entierAAfficherPlus1 = entierAAfficher + 1;
  if(entierAAfficherPlus1  == 3){
    cout << entierAAfficherPlus1  << endl;
  }
  cout << entierAAfficher  << endl;
}
 
int main(){
  int unEntierQueLonVaAfficher = 2;
  afficheEntierPlus1PuisEntier(unEntierQueLonVaAfficher);
  return 0;
}

Bravo et courage !

[Gui13]

Ah! Merci pour ces réponses, j'y vois un peu plus clair.

Pour expliquer un peu la démarche: je suis dans une boite qui a un code assez bizarre en C++ (avec tout un tas de macros pour déclarer les classes, une config en XML et des choses que je ne comprends pas encore).

En naviguant dans le code j'ai trouvé des fonctions où justement le nom de variable dans un if{} était le même que l'argument que la fonction recevait. C'est (je pense) à des fins de lisibilité, puisque dans mon cas le nom des méthodes est fait de manière à sembler plus naturel:

Code :

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

1
2
Request request(...);
request.Answer();

Donc que ce soit la requête "recue" ou la requête à "renvoyer", ils utilisent le même nom de variable pour plus de lisibilité.

L'exemple au dessus m'a juste aidé à confirmer que ca marchait. Dans la réalité, de mon côté, je trouve ca un peu débile...

[Feriaman]

Donc que ce soit la requête "recue" ou la requête à "renvoyer", ils utilisent le même nom de variable pour plus de lisibilité.

Je serais vraiment intéressé de voir un code dans lequel le masquage de variables rend le code plus lisible. En général, c'est le contraire.

Peux-tu nous le montrer ?

L'exemple au dessus m'a juste aidé à confirmer que ca marchait. Dans la réalité, de mon côté, je trouve ca un peu débile...

Il y a quelques mois, j'ai été amené à aider un collaborateur qui n'arrivait pas à débuger une vielle application à cause d'un problème similaire (bon il ne s'agissait pas de masquage, mais de réutilisation d'une variable).

A cause de cela, le pauvre avait étudié pendant 3 jours la mauvaise partie du code.

Un bon code devrait être facilement maintenable pour éviter ce genre de choses. En général l'utilisation du masquage nuit à cet objectif.

[Gui13]

Non c'est pas possible pour le code je pense (CND) mais c'est dans l'esprit du code au dessus:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
int foo(Request & request){
   if (configured(request))
   {
      Request request(...arguments...);
      send(request);
   }
   request.Answer():
   return 0;
}