C
C++
Python
Ruby
Java
C#
PHP
Matlab
HTML/CSS
OCaml
C'est justement là le problème : 'c' est un caractère, mais pour le langage c'est d'abord un entier. En matière de typage fort, on fait mieux !
Et 'c' vaut 99 en ASCII, 129 en EBCDIC. Bonjour la portabilité du code !
Conceptuellement, utiliser 'c' comme un entier peut se comprendre dans quelques très rares situations (boucles, par exemple). En dehors de ça, il n'y a aucune raison logique de s'en servir comme entier.
Au strict minimum, le langage devrait exiger un transtypage pour effectuer une opération arithmétique sur un caractère.
Donc, j'insiste : C n'est pas adapté à l'apprentissage de la programmation.
Là où le bât blesse, c'est que dans d'autres langages, c'est que 'c' + 2 fait 'c2'.
Donc la question "quelle est la sémantique ?" est extrêmement pertinente, car elle est justement tout sauf triviale.
Bon. Après, je n'aurai pas pris 'c'+2 comme démonstration des problèmes du C pour des débutants.
'c' est un caractère, point. Sa représentation ASCII n'est pas un entier mais 7-bits, son codepoint Unicode est effectivement un entier 32-bits. Mais ce n'est pas le cas des caractères décomposés en Unicode.
Rien que ce micro "débat" est une preuve du problème.
Et C et en C++, 'c' est un char, un char est un entier.
'c' correspond à la valeur ASCII du caractère c mais n'est en rien un caractère.
Ce qui est super clair pour un débutant... (pour en revenir au débat)
Après, 'c' ne va pas forcément correspondre à la valeur ASCII de la lettre c en minuscule. Cela pourrait être de l'ECBDIC -- grâce à qui nous risquons de continuer à avoir des trigraphes en C++17. Tout dépend de l'encodage du fichier source.
Oui, c'est bien pour ça que la confusion est possible : "char" signifie "caractère". Si on veut parler d'un entier sur 8 bits, on devrait utiliser un autre mot. Qui n'existe évidemment pas en C.
Car si on fait un printf('c'), on obtiendra c. Pas autre chose. Et pourtant, vu par le compilateur c'est aussi un nombre !
Autrement dit : 'c' est un caractère, du point de vue sémantique & un nombre du point de vue du compilateur. Bref, ça oblige à être toujours très attentif à ce qu'on écrit, car ce qui peut être juste pour le compilateur (& à l'exécution du programme) peut être parfaitement absurde du point de vue de la logique de l'écriture, donc de la pensée du développeur. En tout état de cause, ça ne facilite pas la relecture du code, donc son éventuel débogage.
Encore dit autrement : il est absurde d'écrire 'c'+2 si c'est juste pour calculer 99+2.
Je vais répéter ce que dit Bousk mais à ma manière, c'est à dire en étant chiant :
Je ne vois pas en quoi il serait absurde d'additionner un caractère et un entier, du moment qu'on peut donner une définition formelle d'une telle opération.
1) L'alphabet est une liste ordonnée de caractères : abcdefghijklmnopqrstuvwxyz
(en fait il peut y avoir beaucoup plus de caractères que dans mon exemple, par exemple il y en a 256 dans le jeu iso-latin-1)
2) Si c est le caractère d'indice n dans l'alphabet, et si i est un entier, c + i est le caractère d'indice n + i dans l'alphabet.
Voilà : on a défini une addition entre un caractère et un entier. Cela se tient théoriquement, cela a une utilité pratique, et cela est (relativement) indépendant de la représentation exacte des caractères.
Les concepteurs d'un langage ont donc le droit de faire un tel choix. (Et j'ajouterais que ce choix se tient suffisamment pour ne pas être un bon argument contre le C...)
Même si d'autres choix sont possibles, comme l'exemple 'c' + 2 = 'c2' cité par Luc Hermitte.
De toute façon le C est un des meilleurs langages pour débuter précisément parce qu'il est un des pires... paradoxal isn't it ?
Oui, c'est un choix qui semble raisonnable.
Mais en pratique je ne connais pas de langage qui a fait ce choix (et en particulier pas le C où, bien que fonctionnant sur plusieurs implémentation, n'est qu'une conséquence de la confusion caractère/entier, n'est pas garanti et donc non portable).
Je ne vois pas le problème dans le langage. Le problème dans ce topic est la pluie d'assertions absurdes.
C'est vraiment n'importe quoi comme argument.
Le fait que les gens ne soient pas d'accord ne prouvent absolument RIEN, sauf le fait que la moitié des assertions dans ce topic sont grossièrement fausses.
Non, on n'obtient rien.
Du point de vue du compilateur, 'c' est seulement un nombre. Pas autre chose.
C'est quoi le "point de vue sémantique"?
Comme toujours en programmation.
Si tu oublies ça, j'espère ne pas avoir à utiliser tes programmes!
Comme toujours en programmation.
Alors ne l'écris pas!
Cool.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9 void f (int b[3]) { printtf ("sizeof b = %d\n", sizeof b); } void g () { int a[3]; printf ("sizeof a = %d\n", sizeof a); f (a); }
Le résultat de l'opération.
La norme n'impose pas de charset ni que les lettres soient contigües dans le charset utilisé par l'implémentation (elles le sont en ASCII mais pas en EBCDIC par exemple). Et donc il n'est pas garanti que 'i' + 1 soit égal à 'j' (ce n'est effectivement par le cas en EBCDIC).
En pratique, les implémentations où les lettres sont contigües sont largement répandues, le problème est donc assez marginal. Mais il n'y a aucune garantie.
http://codepad.org/ktMS89K2
Code : Sélectionner tout - Visualiser dans une fenêtre à part Segmentation fault
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager