Discussion :

[exhortae]

Bonjour

Voilà je cherche à modifier la valeur d'une constante à travers un const_cast.

j'utilise le code suivant :

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
16
17
18
19
#include <iostream>
 
using namespace std;
 
int main ()
{
   const int constvar = 33;
 
   const int* ptr_c = &constvar;
   int* ptr = NULL;
 
   ptr = const_cast<int*> (ptr_c);
 
   *ptr = 66;
 
   cout << constvar;
 
   return EXIT_SUCCESS;
}

normalement à l'execution constvar devrait avoir la valeur 66, pourtant elle garde la valeur 33

Merci

[Médinoc]

Il est possible que constvar soit stocké dans une zone mémoire en lecture seule, mais ce serait plus du genre à planter.

Je pense plutôt qu'il y a une optimisation, et que gcc suppose que constvar est égal à 33 et donc, ne la re-lit même pas.

[nikko34]

faut avoir de sérieuses raisons pour vouloir faire ça..

[ac_wingless]

Je pense aussi qu'il s'agit d'un problème d'optimisation... le problème ne se pose pas avec d'autres types que des entiers, et si on met "volatile int" ça marche.

C'est tout de même curieux.

J'ai lu qu'il y a beaucoup de problèmes actuellement dans le modèle mémoire de C++, et que c'est en cours de redéfinition pour C++0x pour préciser comment les optimisations peuvent être faites (pour prendre en compte les optimisations agressives, en particulier les conflits de cache entre cœurs).

Je ne suis pas familier de ces problèmes, et je dois dire que ce genre de comportement indéfini est plutôt perturbant.

[Sylvain Togni]

En quoi est-ce curieux ? Ce n'est pas du C++ valide, ça peut afficher 33 comme reformater le disque dur.

[nikko34]

Je ne suis pas familier de ces problèmes, et je dois dire que ce genre de comportement indéfini est plutôt perturbant.

ce qui est perturbant c'est ce que tu veux faire

[gb_68]

Une variable const int peut être directement remplacée par sa valeur dans le code, si elle est connue à la compilation, ce qui permet notamment de les utiliser pour définir un tableau static (remplaçant par exemple certains #define)
ex:

Code :

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

1
2
3
4
5
6
7
{
    // #define Taille 10
    // avantage : la portée peut être limitée
    const int Taille = 10;
    int Tab[Taille];
    ...
}

Et le compilateur peut même ne pas l'allouer physiquement si ce n'est pas nécessaire.
Par analogie, une fonction inline peut être étendue ou pas (code pas disponible, appel récursif ...). Si tu prend son pointeur et que tu "hook" la fonction (en remplaçant le début de son code -- après éventuellement fait sauté la protection de la mémoire),
tu n'impacteras évidemment pas les endroits où elle a été "inlinée".

[Emmanuel Deloget]

Il est possible que constvar soit stocké dans une zone mémoire en lecture seule, mais ce serait plus du genre à planter.

Je pense plutôt qu'il y a une optimisation, et que gcc suppose que constvar est égal à 33 et donc, ne la re-lit même pas.

Non, constvar n'est pas en lecture seule. Par contre, le compilateur considère qu'il s'agit d'une constante intégrale - donc chaque fois qu'il y est fait référence dans le code, elle remplace l'identifiant par la valeur. Le fait que l'adresse de la constante existe ne signifie pas que la constante est modifiable via son adresse - seulement qu'il existe une zone mémoire ou la valeur de la constante est stockée.

Ce programme:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <iostream>
 
int main()
{
	const int cvar = 33;
 
	int* var = const_cast<int*>(&cvar);
	*var = 66;
 
	std::cout << "pointers - var: " << var  << " - &cvar: " << &cvar << std::endl;
	std::cout << "values   - var: " << *var << " -  cvar: " << cvar << std::endl;
 
	return 0;
}

Qui affiche (compilé avec VC++ 2005) :

Code :

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

1
2
pointers - var: 0012FF60 - &cvar: 0012FF60
values   - var: 66 -  cvar: 33

Le code assembleur généré est le suivant:

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
 
// la seconde partie du deuxième appel à std::cout: 
x00414186  mov         esi,esp 
x00414188  mov         eax,dword ptr [__imp_std::endl (41A308h)] 
x0041418D  push        eax  
x0041418E  mov         edi,esp 
x00414190  push        21h    /// <------ 33 :)
x00414192  push        offset string " -  cvar: " (417710h) 
x00414197  mov         ebx,esp 
x00414199  mov         ecx,dword ptr [var] 
x0041419C  mov         edx,dword ptr [ecx] 
x0041419E  push        edx  
x0041419F  push        offset string "values   - var: " (4176FCh) 
x004141A4  mov         eax,dword ptr [__imp_std::cout (41A304h)] 
x004141A9  push        eax

Par contre, si cvar est une constante globale, elle sera alors mise dans le segment rodata (et sera donc en read-only). Ce programme:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <iostream>
 
const int cvar = 33;
 
int main()
{
	int* var = const_cast<int*>(&cvar);
	*var = 66;
 
	std::cout << "pointers - var: " << var  << " - &cvar: " << &cvar << std::endl;
	std::cout << "values   - var: " << *var << " -  cvar: " << cvar << std::endl;
 
	return 0;
}

génère une exception 0xC0000005:

Code :

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

First-chance exception at 0x004114d8 in cvar.exe: 0xC0000005: Access violation writing location 0x004176fc.

Avant de terminer, je voudrais insister sur un point: ce n'est la que le comportement d'un compilateur parmi d'autres. Le standard actuel est explicite sur le sujet (section 7.1.5.1 [dcl.type.cv], §4):

... any attempt to modify a const object during its lifetime (...) results in undefined behavior.

Pour autant, si votre compilateur se met à formater votre disque dur, je n'ai qu'un seul conseil à donner : changez-en.

[Médinoc]

Moi, j'ai préféré une DS9K : Chaque fois que j'ai un comportement indéfini, ça balance un missile nucléaire quelque part dans le monde.

[exhortae]

Avant de terminer, je voudrais insister sur un point: ce n'est la que le comportement d'un compilateur parmi d'autres. Le standard actuel est explicite sur le sujet (section 7.1.5.1 [dcl.type.cv], §4):

Oki, sur mon vieux livre il utilisaient borland c++ et ça marchait, mais bon je trouvais ça un peu tordu de pouvoir modifier une constante.

Merci

[ac_wingless]

une petite recherche google intéressante:

exhortae, ce lien contient une discussion exactement sur ce sujet, en particulier comment le langage D distingue entre les deux forms de const mélangées en C++,
- le "const int", qui définit l'invariance réelle d'un objet (il peut par exemple être implémenté en ROM)
- et le qualificateur d'accès au travers du pointeur "const int*", qui dit seulement la manière dont on voit la zone pointée (les droits d'accès sont alors modifiables par const_cast).
ce que l'auteur nomme "const as a storage class, and const as a type attribute."
Dans votre exemple, le const_cast s'applique non pas à la classe de stockage, mais au droit d'accès.

Apparemment, en D, on peut distinguer ces deux concepts, alors qu'en C++, la distinction se fait selon que le qualificateur const est appliqué ou non au premier niveau d'une déclaration.

[exhortae]

une petite recherche google intéressante:

exhortae, ce lien

Merci pour le lien

[corrector]

Je pense aussi qu'il s'agit d'un problème d'optimisation... le problème ne se pose pas avec d'autres types que des entiers, et si on met "volatile int" ça marche.

Avec la version que tu utilises de ton compilateur, peut-être (mais es-tu sûr d'avoir testé tous les cas?).

Avec d'autres compilateurs, ce que tu appeles "le problème" peut exister avec d'importe quel type.

C'est tout de même curieux.

En quoi?

J'ai lu qu'il y a beaucoup de problèmes actuellement dans le modèle mémoire de C++, et que c'est en cours de redéfinition pour C++0x pour préciser comment les optimisations peuvent être faites (pour prendre en compte les optimisations agressives, en particulier les conflits de cache entre cœurs).

Il n'y a aucun problème avec le "modèle mémoire" à cause du fait que l'on ne puisse pas modifier une constante. (En C non plus on ne peut pas modifier une constante. Est-ce que le modèle mémoire va être modifié pour autant?)

Tu veux probablement parler de l'introduction du multithread en C++, et du fait que le modèle mémoire est redéfini par rapport à l'exécution de plusieurs threads. Ce qui doit définir ce que les implémentations peuvent faire en multithread (donc les optimisations permises), mais n'a pas pour but de préciser les optimisations possibles sur du code mono-thread.

Sinon, le multi-core n'est juste du multi-processeur - et encore pas tout à fait : il y a deux espèces différentes de "multi-core" (différents au niveau du partage du cache) correspondant plus ou moins exactement au multi-processeur classique, d'après ce que j'ai compris.

Les conflits de cache sont gérés automatiquement au niveau matériel, et c'est parfaitement transparent (sauf au niveau des performances). Le programmeur n'a pas affaire au cache, même au niveau assembleur, sauf dans les cas où une donnée est accédée derrière le dos du cache : accès directe à la mémoire par un périphérique, et modification du code exécutable.

Je ne suis pas familier de ces problèmes, et je dois dire que ce genre de comportement indéfini est plutôt perturbant.

Qu'est-ce que tu essaies de faire, au final?