'jour a tous,
 
je voulais savoir a quoi correspondent les caractères tels que '\r' ou '\n' en fin de string et surtout a quoi  ils correspondent en hexadecimale ou en binaire.
 
Est il possible de les reproduire grace au clavier, si oui comment ?
 
merci de votre aide

Comme l'indique ton livre de C, '\n' est le caractère de fin de ligne et '\r' est le caractère de retour en début de ligne. A noter que le plus souvent, le caractère '\n' provoque le retour en début de ligne et l'avance d'une ligne.

Et en décimal ou en octal, ça ira ?
 
'\n' correspond en ASCII à la fonction LF (Line Feed) de valeur 10
'\r' correspond en ASCII à la fonction CR (Carriage Return) de valeur 13
 

C'est pas évident. En général <enter> génère '\n' et ctrl-enter génère '\r', mais ça peut changer d'une machine à l'autre ou d'un système à l'autre.
 

pourquoi tu dis pas tout simplement que la valeur entière d'\n' est (int)'\n' ?

Parce que le cast est inutile vu qu'une constante caractère est déjà un int (en C, pas en C++)

oui, mais tout le monde comprends pas que la valeur de '\n' c'est '\n'
 
je me suis mal exprimé

 
C'est pas évident, pour un débutant, d'assimiler qu'un caractère est déjà un nombre qu'on peut utiliser tel quel    
=> 'a' + 1 = 'b'
=> '9' - '0' = 9

on peut mais est-ce portable ?

Non.

Oui.

 
Ah ?  
Pourquoi ?

Parce que le langage C ne garanti pas que le charset soit ASCII. En EBCDIC, les valeurs des caractères alphanumériques ne sont pas toutes consécutives.
 
http://www.natural-innovations.com [...] bcdic.html
 

mais est-ce que c'est surréaliste d'imaginer d'autres jeu de caractères ?

Unicode ? é+1, ça fait quoi ? f' ?
 
Sinon EBCDIC est d'usage sur mainframe IBM (AS-400 etc.)

oui, je pense exactement ça genre de chose. d'ailleurs strtod et ses amis sont dépendants des locales ce qui conduit souvent au massacre.

Je viens d'aller voir le lien donné par Emmanuel.  
EBCDIC c'est clairement une table de malade, s'il n'y avait ce semblant de logique j'aurais pu croire qu'ils ont joué à boggle en concevant ça.
Enfin, y avait surement de bonnes raisons derrière, j'imagine.

La raison c'est que c'etait fait pour les cartes perforees :
http://www.cs.uiowa.edu/~jones/cards/codes.html

Je ne suis pas étonné, je pensais à quelque chose dans ce goût-là quand j'ai vu les groupements de lettres.
Ca n'en reste pas moins une table de malade  

Bon, on peut présumer que les codes qu'on développe aujourd'hui n'ont pas besoin d'assurer la compatibilité ascendante pour les systèmes à carts perforées, je suppose
Sinon, je viens d'apprendre un truc là (même si naturelement, je sens bien qu'il vaut mieux éviter de faire des trucs moches comme les "soustractins de caractères" ).