si on veut créer une variable qui change pas (const), ben on a qu'a pas la changer non ?
pourquoi créer un const ? pour éviter que la variable change par magie ?

pareil pour les unsigned, si on veut qu'elle soit strictement positif, mais on a qu'a pas la changer en nombre négatif ..

alors, pourquoi ??

"pourquoi créer un const ? pour éviter que la variable change par magie ? "

Par sécurité, pour que le compilateur optimise un peu le programme

Et les usigned ça augmente aussi la valeur maximum que peut avoir une variable, genre un char signé c'est de -127 à 127, et un unsigned c'est de 0 à 255

Et aussi pour des questions de "logique".

Une boucle qui parcours un tableau, ce n'est pas logique d'avoir un entier signé étant donné que tu ne travailles que sur des indices positifs.
De même pour une taille de liste par exemple, le nombre d'éléments est toujours positif.

C'est moins un probleme d'optimisatio qu'un probleme de faute du developpeur. Si tu met une variable const et qu'elle se retrouve a changer, le compilateur va te hurler dessus. Donc ca te permet de voir une difference entre ce que tu voulaus faire et ce que tu as fait concretement. Beaucoup de bug viennent de situation comme ca.

Pour compéter un peu la réponse pour les unsigned :
Dans un char représenté par un octets ( = 8bits) il y a un bit de réservé pour le signe, cela permet entre autre de pouvoir "augmenter" la valeur d'un char signé.
char a = 8; // 00001000
a = -8; // 10001000

C'est utile pour des compteurs de temps (pas de temps négatif, mais si tu compte en secondes tu vas avoir besoin d'un maximum de taille), pour des protocoles réseaux...

Les humains font des erreurs, et il n'y a pas qu'une seule personne qui travaille sur un même code.

"Les humains font des erreurs" à commencer par à peu près tout le monde ici.

Pour commencer, vous pouvez jeter le message de dark_drow qui nous déballe la théorie du complément à 1. Il a bien retenu sa leçon... sauf que ça fait des décennies qu'on sait qu'il faut faire (et donc qu'on fait) du complément à 2.

Du coup :
1/ le plus petit char signé représentable exactement c'est -128 (et pas -127).
2/ la différence entre signed char et unsigned char est purement sémantique : au niveau assembleur/circuit, c'est 8 bit de données, et le résultat est *exactement* le même qu'on mette des unsigned ou non (seuls quelques bits de contrôles changent, mais pas les résultats des calculs).
3/ (corollaire de 2) les perfs sont exactement les mêmes avec ou sans unsigned.
4/ les timestamps peuvent très bien être des signed... la différence sera quand même positive.

Bref, ces informations de type (const, unsigned, etc.) ne servent qu'à donner des précisions sur la nature des valeurs attendues. Cela conduit à deux choses : éviter aux autres développeurs de faire erreurs (comme passer un négatif à une fonction qui attend un positif par exemple) ; et permettre au compilateur de générer d'avantages de warnings. Par contre, vous n'optimiserez absolument rien comme ça.

"Pour commencer, vous pouvez jeter le message de dark_drow qui nous déballe la théorie du complément à 1. Il a bien retenu sa leçon... sauf que ça fait des décennies qu'on sait qu'il faut faire (et donc qu'on fait) du complément à 2."

Cependant, il est important de se rappeller que les normes C et C++ ont ete ecrite sans qu'elles ne specifient si la machine doit etre complement a 1 ou complement a 2. Et que ca fout un peu le bordel dans des trucs obscures.

Pour commencer, vous pouvez jeter le message de dark_drow qui nous déballe la théorie du complément à 1. Il a bien retenu sa leçon... sauf que ça fait des décennies qu'on sait qu'il faut faire (et donc qu'on fait) du complément à 2.

fail, méaculpa, au moins ça aura pull une bonne explication .

Par contre pour les timestamps...? je veux bien une explication car je comprend pas ce que tu veux dire. Tu es en train de dire que si ton timestamp dépasse la valeur d'un signed int (souvent le cas) tu peux quand même faire des calculs exacts avec ?

" Par contre, vous n'optimiserez absolument rien comme ça. "

C'est pas forcément vrai, le code généré par les compilateurs peut être différent avec des const ou des unsigned, ça peut donner du code un peu plus efficace dans certains cas.

En passant, certaine des optimization que le compilateur fait dans ton dos peuvent representer un reel probleme:

http://developers.slashdot.org/story/13/10/29/2150211/how-your-compiler-can-compromise-application-security

dark_drow : Je vais faire l'explication sur un exemple : (-126) - (110) = 20 (c'est -236 modulo 256 pour être précis).

Les histoires de soucis à cause d'overflow dans les timestamps sont des légendes./

J'ai pas précisé, mais si ton signed char est passé de 110 à -126, il a bel est bien été incrémenté 20 fois de 1.

Notons qu'il peut quand meme y avoir un probleme d'overflow. Si ton char passe de 127 a -128, tu ne peux pas differencier une incrementation de 1 d'une incrementation de 257.

sauf que ton timestamp est au pire sur 32 bits, et qu'une durée de plus de 2^32 secondes n'a aucun sens (ou en tout cas il fallait compter en jour voire en an).

en vrai c'est un probleme dans les processeur d'intel, les registre de la PMU sont plutot court (16 bit je crois). Du coup, c'est le bordel pour monitorer ce qui se passe au niveau du CPU. Il faut vraiment que le monitoring des registres de performances soit fait au niveau du noyau, sinon tu perd de l'ifnormation. (Ce qui a principalement amene a PAPI et aux interfaces perf de linux.)

c'est avant tout informatif, surtout const avec les pointeurs en arguments. c'est
bien utile quand on utilise une spec comme opengl, on voit tout de suite quel
fonction modifie un buffer ou pas.

au niveau des performances, il ya des différences dans de rares conditions: division
par multiple de 2, constant folding, ... des optimisations qui dépendent du compilateur
et n'ont pas un grand intérêt 99% du temps.

il y aussi la macro fusion sur les processeurs intel (2005) et amd (2010). quand
le processeur décode le cache d'instructions, il regarde si il peut fusionner
plusieurs macro instructions vers une seule micro instruction. ca se fait surtout
avec des instructions de comparaison de nombres non signés suivit d'un saut (utile
pour les boucles et if-else).

une autre différence, qui m'avait joué un mauvais tour quand j’ai implémenté un
générateur de nombres aléatoires, c'est l’opérateur >> qui n'a pas le même
comportement si l'entier est signé ou pas (instruction sar ou shr sur x86).

tout ca pour ne rien dire a part que le choix entre signé et non signé relève surtout
du bon sens. par exemple, on prendra un signé pour un compteur d'altitude et un non
signé pour un compteur de vitesse. sinon il y a java

"au niveau des performances, il ya des différences dans de rares conditions: division
par multiple de 2, constant folding, ... des optimisations qui dépendent du compilateur
et n'ont pas un grand intérêt 99% du temps. "
ces optimisations qui font que certains de mes codes sont 30% plus rapides, et surtout qui n'ont absolument rien à voir avec l'ajout de const ou unsigned... bravo champion.

Quand on ne sait pas de quoi on parle, on ferme sa gueule. C'est si compliqué que ça à comprendre, putain ?

Du calme chris, elite sait de quoi il parle en moyenne.

Mais c'est vrai que je ne vois pas beaucoup d'optimisation qui sont rendu possible par const. Parceque const ce n'est pas l'oppose de volatile. volatile ca dit que le contenu de la variable peut changer automagiquement et que donc il faut la lire explicitement a chaque fois qu'elle est acceder. Et const ce n'est pas l'inverse de volatile. Ce qui veut dire que si c'est un type "direct" (je veux dire "non pointeur"), alors le compilateur est deja libre de faire des optimisations sur cette variable en la transferant en registre une fois pour toute. Et si c'est un type pointeur, le compilateur ne peut pas faire grand chose parce qu'il peut y avoir de l'aliasing (et tu peux aider le compilateur avec __restrict__, mais const n'a rien a voir dans cette affaire).

unsigned ca n'est pas tres utile non plus en terme d'optimisation, a part virer toutes les comparisons >=0 et <0 qui en fait n'ont pas de sens.

elite, tu as un exemple precis ou const ou unsigned fait une vraie difference en temps de calcul? (ou meme une difference tout court?)

Pour unsigned comme il l'a dit il y a par exemple les divisions par multiple de 2 car pour les nombres négatifs l'arrondi n'est pas conforme à la convention avec un simple décalage de bits. Donc si l'entier est signé il faut rajouter quelques instructions en plus dans le cas où il serait négatif afin d'avoir un arrondi correct.