Discussion :

[Neckara]

Sémantiquement cela n'a pas de sens. Cela n'a de sens que pour la représentation actuelle des caractères. Certes cette représentation ne risque pas de changer, mais cela reste une aberration d'un point de vue purement conceptuel.

En quoi?

'c' n'est pas un caractère mais un entier.

[ALT]

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.

[Luc Hermitte]

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.

[Logan Mauzaize]

'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.

[Neckara]

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.

[Luc Hermitte]

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.

[ALT]

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.

[gl]

Et C et en C++, 'c' est un char, un char est un entier.

C'est vrai en C++, pas en C ou 'c' est un int (mais "azerty" est bien un ensemble de char, histoire de complexifier un peu plus).

[Bousk]

Sémantiquement cela n'a pas de sens.

En quelle honneur ?
Si j'ai envie que ça signifie "2 lettres après c dans mon alphabet", j'ai pas le droit ?

[CodeurPlusPlus]

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 ?

[gl]

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.

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).

[abel.cain]

'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.

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.

[abel.cain]

Sa représentation ASCII n'est pas un entier

Pardon?

[abel.cain]

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.

Non, on n'obtient rien.

Pas autre chose. Et pourtant, vu par le compilateur c'est aussi un nombre !

Du point de vue du compilateur, 'c' est seulement un nombre. Pas autre chose.

Autrement dit : 'c' est un caractère, du point de vue sémantique

C'est quoi le "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

Comme toujours en programmation.

Si tu oublies ça, j'espère ne pas avoir à utiliser tes programmes!

, 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.

Comme toujours en programmation.

Encore dit autrement : il est absurde d'écrire 'c'+2 si c'est juste pour calculer 99+2.

Alors ne l'écris pas!

[abel.cain]

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.

Pardon?

Qu'est-ce que l'encodage vient faire ici?

'c' correspond à la lettre "c", par définition.

[abel.cain]

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 ?

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);
}

[abel.cain]

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).

Qu'est-ce qui n'est pas garanti?

[gl]

Qu'est-ce qui n'est pas garanti?

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.

[gl]

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.

Non, on n'obtient rien.

Ca dépend de ce que l'on entend ici par obtenir mais :

• Sur la sortie standard on obtiendra bien le caractère c.
• En retour de la fonction on obtiendra 1 (ou une valeur négative en cas d'erreur).

[abel.cain]

Ca dépend de ce que l'on entend ici par obtenir mais :

• Sur la sortie standard on obtiendra bien le caractère c.
• En retour de la fonction on obtiendra 1 (ou une valeur négative en cas d'erreur).

http://codepad.org/ktMS89K2

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Segmentation fault