je viens de tomber sur un bug mignon
 

 
et non, char c'est ni signed char, ni unsigned char, c'est char. Et avec une const&, ça se traduit par une const& vers une variable temporaire constante

j'ai pas tout compris de ce qui est prouvé ici, mais en tout cas sur mon compilo (vc++7.1) ca compile pas non plus avec des int a la place des char/unsigned char.

bah trouve toi un compilo décent alors. Le code est valide mais ne fait pas forcément ce qu'on croit.

bref si ton compilateur compilait, quel serait le résultat ?

oui, c'est tout mimi
 
la clé, c'est que 'unsigned char' et 'char const' ne sont pas rérérence-compatible, et ne sont pas de class type évidemment.
Donc, comme tu l'as dit, ça entraine la création d'un temporaire via copy initialisation avec conversion standard (lvalue-to-rvalue -> conversion entière -> cv-conversion ). Après la chose amusante, c'est la durée de vie du temporaire, qui est détruit à la fin de la vie de uc.
 
Ce qui est amusant aussi, c'est de compter le nombre de fois ou visual est à la ramasse des qu'on sort des sentiers battus.

apparement sur g++/gcc 3.2.2 le programme retourne 1 (en tout cas il retourne pas 0
 
[dev@ServeurRH test]$ g++ test.c
[dev@ServeurRH test]$ ./a.out && echo test
[dev@ServeurRH test]$ g++ --version
g++ (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
 
Si j'ai bien compris, la référence devrait référencer une constante mais pointe sur une valeur qui est ensuite modifiée. Si qq1 pouvait m'expliquer, je comprends déjà pas bien pourquoi ca devrait compiler
 
edit : puis a propos de décence de compilo, vc++7.1 n'est pas décent puisqu'il ne compile pas, mais le tien n'est pas décent non plus puisqu'il est buggué, non ?

perso je pige pas pkoi un char & pourrait referencer un unsigned char ?

qu'est-ce qui ne va pas avec l'explication que j'ai "tenté" de fournir ?
 

Ce n'est pas un bug, c'est décrit par la norme, 8.5 et 12.2.

mmh en relisant une 5ieme fois les explications, il me semble avoir à peu pret compris. J'essaye de décomposer ce que le compilo fait, dites moi si j'ai bien compris svp
 

 
mais mon programme compilé ne retourne pas 0, donc j'ai pas du bien comprendre

 
peut etre pour faire en sorte que f et g aient un comportement voisin (au niveau des conversions appliquées à son argument)
 

 
idem ...

je suis pas sur à 100%, mais je crois que c'est bon.
 

bug ? ./a.out;echo $? ne retourne pas 0 ?

sur g++/gcc 3.2.2
si je compile quelque chose comme :
 

 
puis que je tape : (sur rh)
./a.out && echo test
ca m'affiche test
 
si je compile le code ci-dessus et que je tape la meme commande, je n'obtiens aucun affichage

 
heuh ? je te parle de la difference signed / unsigned

jte suis pas la ... Regarde le premier message de Taz : signed char != char && unsigned char != char. Après, il y a des conversions standard qui s'appliquent.

 
Moi ce que je ne comprends pas, c'est qu'une reference sur un "char" puisse porter sur un "unsigned char"
 
jtrouve pas ca logique quoi

OK, je te redonnes l'exemple qui colle à ce que tu cites :    
 

 
si une référence constante sur un char ne pouvait pas porter sur un unsigned char, f ne permettrait aucune conversion entiere sur son parametre tandis que g oui. Je pense que cette règle a été décidée pour qu'un parametre de type T ou T const& se comporte de meme "à la compilation".

mouais
 
pas super convaincu

Vois que le problème est différent avec signed int qui renvoie la version modifiée (càd l’original), sans créer de temporaire (tout comme char ou int tout court). Tandis que char utilisé comme un type numérique (càd à dire avec un modificateur de type explicite), renvoie la copie de la version originale (un temporaire, exactement comme unsigned int, mais pas signed int, goto 0).
 
Il y a clairement redondance entre ‘int’ et ‘signed int’ (par définition).
Par contre  ‘char’ et ‘signed char’ on des sémantiques différentes.
 
Quel qu'en soit le sens*, l’implémentation est consistante. C’est le plus important (surtout quand on songe aux types qui découlent du modificateur 'unsigned' et aux endroits où ils sont utilisés...)
 
Quant à savoir si le code original est valide, un compilo « décent » dirait sûrement ça :
 
[Warning] Ligne 3 : Variable initialisée avec le type int ; j’attendais un unsigned char
[Warning] Ligne 5 : création d’un temporaire
[Warning] Ligne 5 : initialisation d'une référence (constante) sur un char à partir d'un type modifié
[Warning] Ligne 7 : Assignation d'un int à un unsigned char
[Warning] Ligne 8 : La fonction retourne un int, je trouve une référence (constante) sur un char
 
5 Warnings.
 
/*const */ char &a=*"+";

 
oui, signed int const est reference-compatible avec int, alors que signed char const n'est pas référence-compatible avec char.
 

 
avec l'option -Wpedantic-with-the-little-finger-up ?

Vive le typage fort !
Cela peut être parfois un peu lourd mais en tout cas on fait des programmes cohérents.