deleted

 
non ca sert pas a faire joli, ca s'appelle un scope. Sortie de la zone des {} les variables ne sont plus accessibles donc tu économises de la ram.

 
oh putain, un monguer qui se met à fairte du C

 
Ca évite également d'avoir une définition d'une variable, soit en plein milieu du code, soit en début de fonction alors que la variable ne sert que dans une partie très restreinte de la fonction.
Bref, ça peut aussi servir à améliorer la lisibilité du programme.

 
tu peux aussi t'en servir pour "masquer" la définition d'une variable existante... alors la lisibilité...

Je parle bien de "possibilité", pour la lisibilité.
 
C'est juste un argument de plus en faveur du fait que les accolades sont pas là pour faire beau.

 
c'est une construction classique en perl

Non, moi je dis non.
Certes on peut très bien utiliser les particularités de certaines syntaxes pour polluer un programme... mais mis à part dans certaines réunions, ce n'est généralement pas dans ce but là qu'on utilise ces syntaxes.
Pour ma part, je tend à croire que celui qui utilisera un raccourci syntaxique dans son programme le fera dans un but utilitaire (économie de mémoire, économie algorithmique, optimisation, etc...) et non pas pour pourir la vie de celui qui va le relire...

ne jamais présumer de la qualité du code

Bon, déjà, "a += b" est un raccourci qui signifie "a = a + b" (on peut donc faire a -= b, a /= b, a *= b, a &= b, etc).

Quant au code sur lequel tu t'interroges, c'est ultra-simple : dans l'expression "a || b", si a est vrai, alors la condition b n'est pas évaluée (idem pour "a && b" : si "a" est faux, alors "b" n'est pas évalué).

A partir de là, c'est facile de voir ce que fait le code

et ça correspond à quoi les conditions avec des , au milieu ?

truc du jour : en C, un statement renvoie une valeur.  
 
donc a = 20 va renvoyer à un membre gauche 20 (il y est pas, mais si, c'est vrai, tu peux l'affecter, comme  
 

 
 
fait une double affectation.  
 

la même principe marche aussi pour  
 

 
L'expression A>20 est évaluée. Si elle retourne true, c'est pas la peine de continuer dans le OU, donc l'affectation b=10 n'est pas réalisée.  Si elle retourne false, on va continuer d'évaluer l'espression, donc réaliser l'affectation.
 

La première fois que tu l'a écrit en parlant de C# j'ai cru que or était un keyword standard pour ||, ça faisait une soupe assez bizarre à comprendre...

(d'ailleurs ça peut faire mal une variable 'or' si quelqu'un inclut <iso646.h>, qui est un header standard (c99)...)

la , en C est l'opérateur séquentiel, ça veut dire fait ce qu'il y a avant, puis fait ce qu'il y a après, puis renvoie la valeur de ce qu'il y a après.
donc :
rating += 10
age >= 1 (aucun effet de bord)
et enfin: renvoie la valeur de "age >= 1"

( c'est assez rarement utilisé à vrai dire, pour des raisons de lisibilités surtout )

 
le seul cas ou je le vois dans la vraie vie, c'est dans les inits de boucle for.

Bon.

Tu poses cette question :

J'y réponds et, tu remarqueras, sans aucune allusion n'y rien, malgré la trivialité de la question. J'y réponds, tout simplement.

Et je me mange ça :

C'est la seconde fois que je te vois te ramener avec tes gros sabots dans la catégorie C et que je subis ton arrogance.
Alors tu sais quoi ? A partir de maintenant, tu peux aller te faire foutre avec tes questions.

Un truc du genre :
rating += 3*(age<1)+(3-(age>3?3:age))*10;
Ça peut le faire aussi

J'ai cité ta question, pourtant, je me trompe où ?

edit : le fourbe, il a édité sa réponse

Bon, ok, 'dmettons que je me sois enflammé.

"a = b = c + 2" signifie : "c+2 assigné à b, puis b assigné à a"

En plus simple, on peut initialiser en cascade, comme suit : "a = b = c = d = 1;"

J'crois que c'est aussi possible en C#.

La virgule est un opérateur, tout comme le signe "+", "<", "&" et bien d'autres encore.
Ca sert à séquentialiser les opérations.
 
Peut-être que tu as l'habitude de le voir dans les paramètres d'une fonction mais on peut le trouver dans bien d'autres instructions...
int i=0, j=0, k=0;
for (i=0, j=10; i < 100; i++, j--)
free(p), p=NULL;
 
Tu peux même l'y mettre juste pour pourir la vie des autres programmeurs qui bossent avec toi
i=(j=2, 1);
 
Ce qui est une manière tordue d'écrire
i=1;
j=2;
...
 

C'est parfaitement vrai... mais dans le principe je trouve un peu "bancal" de chercher un truc faux pour faire l'affectation.
D'un point de vue purement "logique", je verrais plutôt ça comme "je fais l'affectation si l'assertion est vraie"

 
Ceci dit, cela n'enlève rien à la valeur pédagogique de l'exemple qui ne m'était jamais venue à l'esprit...

dans les paramètres d'une fonction ce n'est pas un opérateur cela dit.

Ah ??? C'est peut-être vrai si tu le dis... mais sincèrement je ne trouve aucun empêchement quelconque à ce que ce soit aussi un opérateur même dans les paramètres.
En effet, lorsque les paramètres sont évalués, ils le sont séquentiellements ce qui correspond donc parfaitement à la fonction de la virgule qui est de séquentialiser ses éléments...  

Non, parce que c'est autorisé en C. Par contre gcc a une option pour signaler le shadowing... : -Wshadow

cette option est dans mon mode paranoïaque :

http://mapage.noos.fr/emdel/codage.htm#cfg_compilo_gcc

Sauf que pour des paramètres, l'ordre d'évaluation n'est pas défini... Grosse différence avec l'opérateur virgule (comma operator)
 

 
J'étais entrain d'aller vérifier dans la norme, tu sais pas ou c'est dedans par hasard ? (à moins que ce soit uniquement spécifié par la non spécification d'un sequence point au moment ou ils parlent de la sémantique d'une définition de fonction)

Pour s'économiser l'appel à sprintf
(après, effectivement est-ce que l'optim est bien nécessaire, j'en doute fortement... mais vu qu'OTTD c'est codé par des assembleux spa étonnant ce genre d'optim, même moi ça me fait mal au coeur les appels à sprintf pour ça )

 
Tiens ? Maintenant que tu le dis, c'est vrai que j'ai déjà eu des surprises avec ce genre de truc
printf("%d %d %d\n", i++, i++, i++)...

C'est ça.
 

Horrible ! Comportement indéfini.

Ah, jl'ai trouvé en explicite, 6.5.2.2.10 \o/

Pour un catalogue des joyeusetés, voir http://www.literateprogramming.com/ctraps.pdf

Archivaid. Merci.
 

Et tu as tort.
Toujours limiter la taille des portées/scopes: le code est plus clair (car les variables sont plus localisées), et plus rapide, car les variables sont sur la pile. Enfin pas en C# et en Java, mais en tout cas tu sollicites bcp moins le GC, puisque la durée de vie des variables s'arrête à la sortie de la portée. (D'aileurs, tu n'es pas sans savoir que ces varaibles s'appellent historiquement des variables automatiques, parce qu'elles sont automatiquement détruites à la sortie du scope.)
Les GC, c'est bien, mais il est tjrs bon de leur faciliter le travail au maximum.

(et oui, le 1er bout de code que tu as montré est assez moche)

 
10, c'est pas beaucoup. D'expérience, 25 est une bonne limite.

Alors on est d'accord.

Le GC (Garbage Collector, je suppose) n'a rien à voir là dedans... Ca ne concerne que la mémoire allouée dynamiquement. En plus, en C, ça n'existe pas en natif.
 
 

Alors par pitié, parles de ce que tu connais et arrêtes de divaguer sur le C. La drogue çay mal tu sais.

Sur un forum C. Mais c'est supair !
 
depuis, le projet en C sur lequel je fais des petits devs, là, ne supporte pas la déclaration tardive. je ne sais pas si c'est typique au C ou un paramètre du projet, mais en tout cas, "for (int i = ...)" lève une erreur de compilation.
 
Bah, cette construction fonctionne en C99. Mais en C90, on fait un bloc et c'est tout.

[C]
Pas si on utilise les variables locales (pas trop grandes). Mais ça dépend de l'usage. Parfois, il faut retourner l'adresse d'un objet alloué dynamiquement. J'espère que le GC ne vient pas se mêler de ce qui ne le regarde pas...
 

Tu sors ça d'où ? Tu as fait des mesures ? Tu peux le prouver.

J'espère qu'il y une injonction t'interdisant d'approcher un compilateur C à moins de 10m, sinon on est perdu.
C'est assez fascinant de voir combien le fait de ne rien paner au C ne t'empeche en rien de pontifier.

Comportement indéfini. Reviens ici quand tu saura de quoi tu parles...
 
On va pas d'embéter sur le forum C#, OK ?
 
Le code manquant est ici :  
http://mapage.noos.fr/emdel/clib.htm
Module CHRO (et les autres si nécessaire...)
 

Un léger overhead, c'est possible. Pas de quoi se taper le cul par terre...

 
Bruit dans la mesure. Parce que si je vire le static des 2 fonctions et que je déplie un vieux gcc 3.4.4 cygming tout moisis,

 
Autrement dit, strictement la même chose.