Discussion :

[Emmanuel Delahaye]

Ahem! Aucune mémoire de données. Elle occupe forcément une place dans la mémoire de code.

Oui, exact.

Mais si elle est assez petite, il est possible qu'elle n'occupe même pas un byte entier (comme la valeur immédiate de l'instruction ADDQ du M68k, qui ne peux prendre que les valeurs de 1 à 8 (oui, 1 à 8, car on n'ajoute pas zéro), donc juste trois bits)... Dans ce cas-là, il apparait parfaitement clair que la constante n'a pas d'adresse.

Même dans tous les cas. Et quand bien même, pour optimiser, la valeur serait placée dans un registre, celui-ci n'a pas d'adresse mémoire (vu du C).

[Emmanuel Delahaye]

Et encore, là aussi, on peut jouer sur les mots. Si la constante a servi à dimensionner un tableau par exemple, la valeur elle-même ne se trouve pas dans le code.

Si, elle va servir à calculer les déplacements, soit comme valeur immédiate, soit dans un registre...

À contrario, on peut définir des champs de bits dans des structures, instanciées en mémoire de données volatile ...

Et ? Tu veux dire quoi ? Qu'un champ de bit n'a pas d'adresse ? Oui, c'est vrai, mais ça n'en fait pas une constante...

J'ai dit que les constantes n'avaient pas d'adresse, pas que les variables avaient toute une adresse (enfin, je l'ai pas dit fort, mais tu as raison, je vais ajouter 'sauf les champs de bits').
.

[Emmanuel Delahaye]

La valeur de cette constante est bien stockée quelques parts non ? Elle a donc une adresse ! mais bon il n'y a pas moyen d'y accéder et je ne vois pas à quoi cela pourrait servir.

EDIT : Vous vouliez peut être dire 'non adressable' ?

La constante a une (ou plusieurs) adresse(s) dans le code, mais elle n'est pas accessible en C. OK pour 'non adressable'. (vu du C, qui est le seul sujet qui nous intéresse ici).

Il existe aussi des codages de mnémoniques dont certains bits sont des constantes. On sait encore moins adresser des bits...

Bref, je ne vois pas trop où est la matière à discussion...

[Emmanuel Delahaye]

1) Le mot-clé « const » est abusif ;

Non. Il est mal compris par les petits malins qui croient qu'on peut coder en C sans ouvrir un livre ou un document de référence. Il ne faut pas se fier aux apparences qui sont souvent trompeuses :

• EOF ne signifie pas fin de fichier
• feof() ne sert part à tester la fin de fichier
• const ne signifie pas constante
• static devant une fonction ne veut pas dire qu'elle est statique

etc.

Chaque mot a une définition bien précise dans le contexte du langage C. C'est ce sens qui compte et pas le langage courant ou l'impression que...

2) À la place, tu proposes « variable à lecture seule » ;

Je ne serais pas étonné de trouver ce terme dans le Rationale...

3) Je faisais remarquer qu'en fait, c'est le terme « variable » lui-même qui est inapproprié.

Etant donné

1 - qu'il s'agit d'un objet mémoire,
2 - qu'il a une adresse,
3 - qu'il occupe de la mémoire,

il est tout à fait approprié de parler de variable. D'ailleurs, en C90, on a pas le droit d'utiliser une variable const pour définir une taille de tableau.

C'est possible en C99 grâce à la notion de VLA, qui accepte une variable comme taille de tableau (const ou non, peu importe).

Ce n'est donc en aucun cas une expression constante telle qu'elle est définie par le langage C.

[Médinoc]

En effet.
Le langage C++ a ajouté à la confusion sur les constantes (justement parce qu'il autorise certaines variables const comme tailles de tableau), mais il n'y a rien de tout ça en C. Une variable const est une variable, est adressable, et on peut même tenter d'y écrore avec un affreux cast de pointeur (même si c'est un comportement indéfini dans le cas d'une variable const en mémoire statique).

[dapounet]

Bonjour,

Ahem! Aucune mémoire de données. Elle occupe forcément une place dans la mémoire de code.

Pourquoi est-ce que les constantes de ce code devraient se retrouver en mémoire ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
int main (void)
{
  volatile int i = 1 << 5;
 
  /* ... */
 
  i *= 2;
 
  if (i != 0)
  {
    /* ... */
  }
 
  return 0;
}

[Emmanuel Delahaye]

Pourquoi est-ce que les constantes de ce code devraient se retrouver en mémoire ?

En tout cas, pas en mémoire de donnée, c'est sûr !

[Médinoc]

En effet, un code optimisé pourrait directement initialiser i à 64, et donc les constantes 1, 5 et 2 disparaitraient complètement.

Mais sans optimisation aucune, on aurait un truc du genre:

Code Assembleur :

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

1
2
3
4
MOV eax, 1
SHL* eax, 5
; ...
MUL* eax, 2

*Ou quel que puisse être le nom de la mnémonique

[Médinoc]

En fait, pour Visual, c'est dapounet qui a raison: Même en mode Debug, optimisations désactivées, le 1<<5 est quand même transformé en 32.
En fait, la seule constante du code source qu'on retrouve dans le code assembleur, c'est le 0 du if.

Code Asm :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
;	COMDAT _TestConstantes
_TEXT	SEGMENT
_i$ = -8						; size = 4
_TestConstantes PROC					; COMDAT

; 48   : {

  00000	55		 push	 ebp
  00001	8b ec		 mov	 ebp, esp
  00003	81 ec cc 00 00
	00		 sub	 esp, 204		; 000000ccH
  00009	53		 push	 ebx
  0000a	56		 push	 esi
  0000b	57		 push	 edi
  0000c	8d bd 34 ff ff
	ff		 lea	 edi, DWORD PTR [ebp-204]
  00012	b9 33 00 00 00	 mov	 ecx, 51			; 00000033H
  00017	b8 cc cc cc cc	 mov	 eax, -858993460		; ccccccccH
  0001c	f3 ab		 rep stosd

; 49   : 	volatile int i = (1 << 5);

  0001e	c7 45 f8 20 00
	00 00		 mov	 DWORD PTR _i$[ebp], 32	; 00000020H

; 50   : 	i *= 2;

  00025	8b 45 f8	 mov	 eax, DWORD PTR _i$[ebp]
  00028	d1 e0		 shl	 eax, 1
  0002a	89 45 f8	 mov	 DWORD PTR _i$[ebp], eax

; 51   : 	if(i != 0)

  0002d	83 7d f8 00	 cmp	 DWORD PTR _i$[ebp], 0

; 52   : 	{
; 53   : 	}
; 54   : }

  00031	5f		 pop	 edi
  00032	5e		 pop	 esi
  00033	5b		 pop	 ebx
  00034	8b e5		 mov	 esp, ebp
  00036	5d		 pop	 ebp
  00037	c3		 ret	 0
_TestConstantes ENDP