Si c'est multithreadé il est toujours possible que le flag soit modifié entre les 2 premiers tests…

Mais bon…

J'aime bien aussi la gestion d'erreur avec seulement un timide printf.

On est jamais trop prudent.

Mais c'est pas un pebcak : c'est un mauvais programmeur.

Oui mais non.

Car dans ce cas, il faudrait déclarer la variable comme étant volatile :
volatile bool flag;

Sinon, l'exécutable ne vérifiera la valeur de flag qu'une seule fois, puisqu'elle est déclarée comme ne pouvant pas changer hors du thread d'exécution courant.

Petit test d'ailleurs, pour ceux qui voudraient voir : créez un programme avec un thread qui ne fait que ça :

int flag = 0;

while (!flag) /* rien */;
printf("Sorti de la boucle");

Et un autre thread qui attend disons 15 secondes et qui fait :
flag = 1;

Compilez en mode debug (gcc -g truc.c -o truc), et exécutez : vous verrez "Sorti de la boucle".

Maintenant, compilez en mode O2 (gcc -O2 truc.c -o truc), et exécutez : votre programme ne terminera jamais. La variable n'étant pas volatile, le code ne la lit qu'une fois (en entrant dans le while).

Tu programmes debout, toi ?

Et je rajoute que, le compilo n'étant pas idiot, quand on a if (condition) else if (!condition) else truc;

Il ignore complètement le else (en générant un warning "unreachable code").

-O2 ça sert pas qu'a "optimiser" le code alors. C'est beau...

Le mec il a peut être fait un langage objet et travaillé qu'avec des objets booléens qui peuvent avoir trois états: Vrai, Faux, Nul.

En fait le langage objet c'est comme la science: it works Bitches!

chrsssh Dechrssssh d'entchrssshde commchrrrsssSSSSSSSSSSSSHHHHHHHHGZZZZCHRRSSSSSSVous m'enSSSSSSSSSSSSSS?

Rah, c'est pas fiable ces machins...

Je suppose que tu veux dire FileNotFound.

http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx

Sauf si le code lui fait faire une synchro comme avec un sleep par exemple :)
Bon pour le !flag, il ne faut pas pousser quand même XD

Faudrai espacer les PEBKAC avec du code source, la page d'accueil fait peur là.

C'est une optimisation. En supposant que le compilo est loin d'être idiot, il teste une seule fois la valeur de flag parce qu'il voit que la valeur de flag ne sera jamais modifiée, alors pourquoi tester à chaque fois si on connait déjà le résultat ?

Sondage : Suis-je le seul a ne pas aimer les indentations a coup d'espaces (que ce soit 2, 3 ou 4) ?
C'est tellement plus pratique un seul caractere (tab) par niveau d'indentation...

Oui

Le problème de TAB est qu'il n'a pas une taille constante suivant les IDE, et donc suivant les programmeurs. Les espaces ont l'avantages de ne jamais corrompre l'indentation.

Le mieux reste donc une indentation par espaces, et un IDE qui sait gérer les mouvements du curseur intelligemment.

Tu pourrais détailler s'il te plait ? Je ne crois pas avoir déjà eu de problèmes avec les TAB.
"Pas une taille constante" ? Un caractère TAB sera toujours 1 caractère TAB non ?
Bref je ne comprends pas, mais je serais ravi si tu pouvais m'expliquer :)

A l'origine, un caractère tabulation était égal à huit espaces. Mais les développeurs trouvaient ça beaucoup trop grand, surtout lorsque les écrans sous DOS n'acceptaient que 80 colonnes de caractères. On a donc vu apparaitre des IDEs autorisant le changement de la taille d'une tabulation... souvent 2 ou 4 espaces.

Très vite, cette fonctionnalité a posée problème lorsque le code source passait d'un développeur à l'autre. Quand on a une indentation mixte tabulation/espace, et que la valeur d'une tabulation change d'un développeur à l'autre, ça casse toute la mise en page...

Les IDEs ont donc trouvé une autre solution : convertir les tabulations en espaces, et traiter les séries d'espaces comme des tabulations pour le curseur. Au final, on utilise plus vraiment le caractère tabulation (sauf sous Python); c'est trop problématique.

on l'a pas tous fait le " printf("On ne devrait jamais arriver ici !");" ? :D

J'ai déjà fais des commentaires "// si vous arrivez ici, il y a un bug" et tu t'aperçois avec le temps que tu finis toujours par tomber dans ces zones théoriquement impossibles.

Autant gérer ça avec un code erreur propre. :)

Il programmait debout, c'est peut-être un détail pour vous, mais pour moi ça veut dire beaucoup

ça veut dire qu'il était libre, heureux d'être là malgré tout...

3 états seulement ? Pfff petit joueur
http://vhdl.renerta.com/mobile/source/vhd00067.htm

Même sous Python, on utilise très souvent des espaces.

En tout cas mixer les espaces et les tabulations, c'est le mal !

Un de mes condisciples avait la particularité de tout faire planter de la façon la plus improbable. Donc à chaque fois qu'on faisait un switch couvrant tous les cas logiquement possibles, on faisait un default: avec un printf("Hubert, comment t'as fait pour arriver là ?");

Et de fait, Hubert arrivait à tomber dans ces cas impossibles.

Une des applications dont je suis responsable contient un grand nombre de cas improbables avec un log:
log.error("THIS IS A BUG !! We should never reach this code");

Je vous dis pas comment ça fait sérieux quand un client tombe sur un log pareil. Je les reformule au fur et à mesure que je les trouve avec des trucs genres "Unexpected option combination foo+bar, please report this error to the application support. Continuing without any of those options." Ca fait quand même nettement plus pro.