Salut HFR
 
Je suis le cours c++ de guillaumme.belz
 
Sur une page (sur les collections) il y a ce code :
 
   

J'en conclu que les boucles for ne prennent en compte que ce qui est indenté ?  Je croyais que les espaces n'avaient pas d'importance  
 
Comment on sait ou elles s’arrêtent ?  Il n'y a pas de {} ouvrantes/fermantes
 
Merci d'avance pour votre savoir  

Bonjour !

Cela n'a rien à voir avec les espaces ou l'indentation, qui, en effet, ne sont pas pris en compte et ne servent qu'à la lisibilité (pas comme en python, donc).

Le contenu de la boucle est soit la "ligne" de code suivante (dont la fin est matérialisée par le point-virgule) suivante, soit le bloc (matérialisé par des accolades) suivant.

Dans le cas qui nous intéresse, les deux codes sont strictement équivalents :

et

Si le bloc ne contient qu'une ligne de code, les accolades ne sont, techniquement, pas obligatoires, cela revient au même, mais, à titre personnel, je les mets toujours.

Si on veut mettre au moins deux "lignes" dans la boucle, il faut absolument définir un bloc avec des accolades.

Bonne continuation !

Tout comme pour les if et autres blocs, s'il n'y a pas les accolades, seule l'instruction suivante est concernée.

L'indentation n'est pas nécessaire

Mais c'est, à mon sens, à éviter. Les accolades devraient être toujours présentes. Leurs absence peut souvent être source de bug, parfois très très grave, comme ce fut en partie le cas du bug TLS/SSL d'apple.

Edit :

Ok merci beaucoup les gars !

 
A quel if correspond le else ?

Je dirais le 2ème
 
Edit : même si, si c'est ça, l'identation n'est pas bonne

c'est bien cela, d'où l'importance de la forme.
 
on aurait pu l'écrire

ce qui n'aurait pas posé de problème au compilateur mais ça devient tout de suite incompréhensible.

C'est clair, je mets toujours les  { }
Après, y'a le débat de les mettre à la "java" ou à la "C"

if (a) {
    cout << "coucou";
} else {
    cout << "toto";
}

 
contre

if (a)
{
    cout << "coucou";
}  
else
{
    cout << "toto";
}

 
Perso, je fais plutôt à la "C" (2ème code).

Comme toi : avec les { } et retours à la ligne systématiques. Même si ça me fait passer pour un vieux rétrograde, je trouve ça considérablement plus lisible.
 
Bel exemple le machin de chez Apple. En même temps l'indentation est foireuse, et ça manque de retours à la ligne entre chaque bloc if distincts. Et puis quelle idée de faire des goto. Bien fait pour eux

C'est vrai que le goto, je pensais que ça avait été abandonné depuis la fin des années 90  

1890 tu veux dire ?

Je crois qu'un certain Linus Torvalds n'est pas de votre avis ...
 
http://koblents.com/Ches/Links/Mon [...] rnel-Code/

Je crois qu'un certain Edsger Dijkstra n'est pas de l'avis de Linus et toi, et qu'il ne l'était déjà pas avant même de savoir que Linus ne serait pas de son avis

... Bon après, je dois reconnaitre que c'est pas forcément un super argument, vu que le monsieur n'était en fait à peu près de l'avis de personne sur tous les sujets

Et , de plus, je n'ai jamais dit que j'étais pour les "goto" ! A titre personnel, je n'ai jamais eu besoin (à part en assembleur) d'en utiliser.

Il y a des cas très précis ou ça peut être efficace, en particulier si tu implémentes a la pogne un automate a états finis.  
Mais a part quelques cas marginaux comme celui la, c'est a proscrire.
 
A+,

Et encore : un automate à états finis, tu peux assez facilement le modéliser avec un réseau de Pétri (donc, des matrices).
En PHP, j'ai utilisé un automate à états finis pour faire une sorte de MVC. Pour se faire, je suis passé par un tableau associatif qui contenait les url des scripts à exécuter en fonction des actions.
 
Tout ça pour dire que la dernière fois que j'ai fait un goto, c'était sur mon Amiga 500, dans un code écrit en BASIC Bref, c'est pas tout jeune !

Je note je note...
 
goto, c'est le mal !  (ça tombe bien que je vois ça parceque j'était tenté justement)

Mettre des goto un peu partout dans un programme, ça le rend surtout assez compliqué à comprendre parce qu'on passe son temps à sauter d'un endroit à un autre dans le code. Alors qu'avec les structures de contrôle classiques (if/else, for, while, switch...), c'est normalement plus lisible et permet une lecture du code plus linéaire donc, plus facile à comprendre et donc, à débugger ou repérer des erreurs