j'ai remarqué que visual donne pour
 
for (int i=0; i<n; i++)
 ...
for (int i=0; i<p; i++)
 ...
 
error: i already defined
 
c'est pas drôle car les autres compilateurs que j'utilise considèrent i comme locale dans la boucle for.
 
je n'ai pas de bouquin de c++ sous la main, donc j'aimerais savoir quelle est la norme. (je suis persuadé que c'est i locale, mais bon)
Ah oui, s'il y a une option dans visual, on peut toujours rêver, pour arranger ça, qu'elle se montre.
 
enfin, j'ai installé le service pack 5 de vc6, et ça n'a rien changé.

Quand tu fais 2 boucles imbriquées, je ne vois pas comment ne pas avoir deux compteurs différents si tu as besoin du compteur dans la boucle.

Le visual a raison, c'est i global. Le for est une autre manière d'ecrire un while :
 
for (A;B;C) {
   D
}
 
est transformé en :
A
while (B) {
  D
  C
}
 
le A, ta déclaration, n'est pas dans la boucle. Il est donc dans le scope supérieur.

elles ne sont pas imbriquées,
elles sont consécutives:
for (int i ...)
{
 ...
}
 
for (int i ...)
{
 ...
}

Je vois bien qu'on peut "expander" un for en while, mais est-ce la norme?

je connais pas VC++ mais quand tu écris :  
 
for (int i=0; i<n; i++)  
...  
for (int i=0; i<p; i++)  
 
tu définis ta variable au moment de la création de la boucle. (Me corriger si je me trompe)
Essaie dans la 2° : for (i=0; i<p; i++) et dis nous si ça plante

Ca marche bien, mais ça rend mon code incompatible avec les autres compilateurs que j'utilise. et je viens de faire un tour sur le site de la norme c++, et je pense bien que visual se trompe:
 
http://www.cygnus.com/misc/wp/dec96pub/stmt.html
 
  6.5.3  The for statement                                    [stmt.for]
 
1 The for statement
          for ( for-init-statement conditionopt ; expressionopt ) statement
  is equivalent to
 
          {
                  for-init-statement
                  while ( condition ) {
                          statement
                          expression ;
                  }
          }
  except  that  names declared in the for-init-statement are in the same
  declarative-region as those declared in the condition, and except that
  a  continue in statement (not enclosed in another iteration statement)
  will execute expression before re-evaluating condition.   [Note:  Thus
  the  first statement specifies initialization for the loop; the condi-
  tion (_stmt.select_) specifies a test,  made  before  each  iteration,
  such  that  the  loop  is exited when the condition becomes false; the
  expression often specifies incrementing that is done after each itera-
  tion.  ]
 
2 Either  or both of the condition and the expression can be omitted.  A
  missing  condition  makes  the  implied  while  clause  equivalent  to
  while(true).
 
3 If  the  for-init-statement is a declaration, the scope of the name(s)
  declared extends to the end of the for-statement.  [Example:
          int i = 42;
          int a[10];
 
          for (int i = 0; i < 10; i++)
                  a[i] = i;
 
          int j = i;        // j = 42
   --end example]

l'exemple d'n bas me semble explicite

Merci pour l'addresse déjà. J'avais oublié un niveau de {} dans l'expansion.

microsoft aussi, cf leur fichier d'aide

d'ailleurs, j'ai envoyé un mail à msdn. S'ils le lisent un jour, je vous en dirai des nouvelles.

Oui! ... et non
La derniere norme te donne raison : i est defini uniquement dans la partie interne de la boucle for...
 
Toutes les precedentes de donnent tors, i est defini dans le scope superieur a la boucle.  
 
Il me semble meme que C ce que tu ecrit est interdit
 
Par contre je ne vois trop de probleme : fait  
int i;
 
for (i...
{
}
 
for(i...
{
}

même pb que toi
du coup, obligé de reprendre plein de choses écrites avant...
m'enfin si t'as du code qui vient d'autres plateformes ou d'autres compilo, ce n'est que le début...
 
un ex bete? snprintf qui est quand même une instruction utilisée doit s'appelle avec _snprintf sous visual.
Euh, a part être imcompatible avcec les autres compilo, je ne vois pas l'interet...

SoWhatIn22 a écrit a écrit : même pb que toi du coup, obligé de reprendre plein de choses écrites avant... m'enfin si t'as du code qui vient d'autres plateformes ou d'autres compilo, ce n'est que le début...   un ex bete? snprintf qui est quand même une instruction utilisée doit s'appelle avec _snprintf sous visual. Euh, a part être imcompatible avcec les autres compilo, je ne vois pas l'interet...

 
snprintf ne fait pas parti (ma connaissance) de la norme tu l'utilises donc a tes risques et perils.
 
Le mieux est d'encapsuler ces choses pour n'avoir a changer l'implementation qu'a un seul endroit. et ce pour TOUT ce qui n'est pas de la norme...
 
la norme C++ ne precise-t-elle pas que ce qui depends de l'implementation doit commencer par _ ?
 
C'est donc MS qui a raison (et ca me fait mal de dire cela)...

SoWhatIn22 a écrit a écrit : même pb que toi du coup, obligé de reprendre plein de choses écrites avant... m'enfin si t'as du code qui vient d'autres plateformes ou d'autres compilo, ce n'est que le début...   un ex bete? snprintf qui est quand même une instruction utilisée doit s'appelle avec _snprintf sous visual. Euh, a part être imcompatible avcec les autres compilo, je ne vois pas l'interet...

 
Je pense que le compilo que tu utilises n'est pas a jour vis a vis des dernieres normes.
Il me semble qu'auparavant, la declaration for (int i=qquechose;...;...) {...} etait equivalente a:
int i;
for (i=qquechose;...;...) {...}  
et ca semble etre typiquement ce qui genere ton message d'erreur
(redefinition de i).
 
Le plus simple dans ces cas la pour avoir un code propre c'est d'effectuer la transformation suivante:
for (i=qquechose;...;...) {...}
  |
  |
  V
{ for (i=qquechose;...;...) {...} }
 
Si c'est le VC++, il y a peut etre une option de compilation ou un pragma qui corrige le pb.
 
A+,