Discussion :

[blanchonvincent]

Bonjour,

J'ai lu dans un livre que :

Code :

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

1
2
const float pi = 3.1415;
(float &) pi = 4;

est possible en C++.

Le livre n'expliquant pas pourquoi, j'aimerais comprendre.
Comment si la variable est déclarer constante peut on la modifier avec un cast par référence.

Pourquoi const_cast<float> pi = 4 ne fonctionne pas ?

Quelqu'un peut il m'éclairer ?

[koala01]

Salut,

le code est possible, mais n'aura normalement aucun effet...

En effet, si tu demande l'affichage de pi après cette opération, tu devrais encore obtenir 3.1415

La raison pour laquelle le code est accepté est simple: tu utilise un transtypage "C style" qui te permet strictement tout et n'importe quoi (il n'y a aucune vérification effectuée)...

Cela te permettrait même de transtyper un F16 en bouquet de fleur, si tel était ton désir

La raison pour laquelle le const_cast n'est pas accepté tel que tu le présente vient de deux erreurs de syntaxe.

En effet, ce n'est pas

Code :

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

const_cast<float> pi = 4;

ni même

Code :

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

const_cast<float>(pi) = 4;

qu'il faut écrire (même si la deuxième syntaxe est déjà plus proche de la solution), mais bien

Code :

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

const_cast<float &>(pi) = 4;

parce que const_cast demande que tu indique que le résultat soit une référence ou un pointeur.

Cependant, le fait que la syntaxe soit acceptée ne veut absolument pas dire que l'instruction aura le moindre effet...

En effet, l'affichage de pi après cette instruction devrait aussi être... 3.1415...

(du moins c'est le cas chez moi)

La raison de cet état de fait est, en définitive, relativement simple:

Les variables constantes prennent place dans un segment de mémoire qui est "read only" (une fois que la valeur est déterminée, il est impossible de la modifier, et la seule utilisation possible de la valeur est... d'obtenir la valeur).

Les deux exemples (cast C style et const_cast) dont il est question ici sont deux contre exemples qui consistent à "mentir" au compilateur pour lui faire croire qu'une valeur n'est pas constante et qui peuvent avoir des conséquences catastrophiques, ne serait-ce parce que, si tu ne vérifie pas correctement la valeur après l'instruction, tu risque de partir du fait que pi vaut...4, alors que ce n'est absolument pas vrai

Ceci dit, et de manière générale, il s'agit de se méfier énormément de toute tentative de suppression de la constante d'un objet.

En effet, tu auras le plus souvent eu de bonnes raisons pour décider qu'un objet (ou que la référence vers cet objet) devait être constant(e)...

La raison principale étant sans doute que... tu souhaite restreindre les actions envisageables sur cet objet, pour t'assurer qu'il ne sera pas modifié.

Le fait de supprimer cette restriction signifie finalement deux choses:

• Soit que tu n'avais aucun besoin d'assurer la constance de l'objet
• Soit que tu veux faire quelque chose qui posera problème en essayant malgré tout de modifier un objet qui n'a pas lieu de l'être

Par contre, l'inverse (décider de transtyper un objet non constant en un objet constant) posera beaucoup moins de problème, parce que tu ne fait que rajouter des restrictions à son utilisation

[blanchonvincent]

Merci beaucoup pour cette réponse, ça commence a être déjà plus clair.

Si je suis ton raisonnement (si j'ai bien compris ), le code ci contre :

Code :

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

1
2
3
const int a = 5;
int & b = const_cast<int &> (a);
b++;

ne devrait pas modifié la valeur de a ?
Pourtant l'affichage de a vaut 6 nan ?

Sinon, la seule raison pour conts_cast d'exister et de pour pouvoir passer à une fonction qui demande un paramètre non constant une constante c'est ça ?

[Arzar]

En effet, l'affichage de pi après cette instruction devrait aussi être... 3.1415...

Koala, avec VS2005, ce code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
const float pi1 = 3.1415f;
const float pi2 = 3.1415f;
const float pi3  = 3.1415f;
 
(float)pi1 = 4;
(float&)pi2 = 4;
const_cast<float&>(pi3) = 4;
 
std::cout << pi1 << std::endl;
std::cout << pi2 << std::endl;
std::cout << pi3 << std::endl;

affiche '4' dans tous les cas.
Il semblerait qu'on ait affaire à un comportement indéfini.

[blanchonvincent]

Cela dépend alors si le compilateur place les constantes dans un "read only".

La norme dit quelque chose à ce sujet ou elle le choix au compilateur de placer les const dans un "read only" ?

[koala01]

Koala, avec VS2005, ce code :

Avec gcc 4.4.1, sans activer le support de la nouvelle norme:

Code :

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

1
2
 
(float)pi1 = 4;

refusé à la compilation (lvalue required as left operand of assignment )
Y compris avec le support C++0x activé (j'aurais pensé que le lvalue references auraient pu changer quelque chose

Code :

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

1
2
3
4
5
6
7
 
(float&)pi2 = 4;
const_cast<float&>(pi3) = 4;
 
std::cout << pi1 << std::endl;
std::cout << pi2 << std::endl;
std::cout << pi3 << std::endl;

affiche '3.1415' dans tous les cas.

Il semblerait qu'on ait affaire à un comportement indéfini.

Il semblerait en effet

@fnnyaert >>Attention, on parle de deux choses tout à fait différentes...
d'un coté, on crée une référence non nommée et non constante vers une variable constante, alors que de l'autre, tu crée une référence nommée mais non constante vers une variable constante

Et là, nous en arrivons au comportement que je qualifiais de dangereux qui consiste à supprimer la constance d'un objet...

Si le but est de modifier un objet constant, pourquoi diable avoir décrété qu'il ne devait pas être modifié

Quant à savoir ce que dit la norme sur le sujet des références non nommées vers des objets constant, et sans avoir vérifié, je dirais sans doute que c'est un comportement indéfini, et donc particulièrement dangereux

[blanchonvincent]

Très bien merci j'ai compris !

[Médinoc]

Parmi les facteurs contribuants à tel ou tel comportement, j'en vois deux:

1. Si la constante est inlinée ou non:
   
   • Si elle est inlinée, les tentatives d'écriture, qu'elles agissent ou non sur la mémoire, ont des chances de laisser l'affichage inchangé parce que la valeur ne sera pas vraiment "lue".
   • Si elle n'est pas inlinée et qu'elle existe réellement en mémoire, une tentative d'écriture peut mener à une violation d'accès.
2. où est déclarée la constante:
   
   • Variable globale: possibilité de déclaration en mémoire à lecture seule, risque de violation d'accès.
   • Variable locale: peut être déclarée simplement sur la pile.

[Goten]

Euh :

Code :

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

1
2
 
(int)var = somexp;

ça compilera pas.. Y'a pas de lvalue à gauche. (un cast renvoie une r-value)

edit : je faisais référence au message de arzar... mais en fait c'est plutôt une erreur de clavier qu'autre chose non?

[Arzar]

Ben si, c'est bien (float)pi1 = 4;
Je rate rarement mes copiers-collés.

Et ça compile avec VS2005 et affiche 4. Je suis aussi surpris que toi.

[Goten]

C'est pas pour rien qu'il est deprecated alors... . Seulement je vois même pas comment ça peut avoir un sens en fait.

Mais apparemment les vieilles versions de gcc laissé passez ce genre de chose aussi (jsuis tombé sur une ML où un gars avait l'erreur "iso c++ forbids cast to non-reference type used as lvalue" après une mise à jour). Par contre je sais pas ce que ça donnait.

[koala01]

Enfin, quoi qu'il en soit, le souhait qui consiste à trouver un moyen d'appliquer une suppression de constante à une valeur déclarée constante doit, quoi qu'il arrive, nous inciter à nous poser la question de l'opportunité d'avoir déclaré cette valeur constante et / ou de celle te vouloir la modifier...

[JulienDuSud]

Ce sujet m'intrigue...

Parce que, imaginons ce code:

Code :

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

1
2
3
4
5
6
 
int a = 1;
const int* b = &a;
int& c = const_cast< int & >( *b );
c = 2; // comportement défini, a == 2
assert( a == 2 );

A mon avis, le comportement ici devrait être que a == 1. Car, c ne devrait pas pouvoir modifier a, du moins pas à partir de b.

Je sais que l'utilisation de const_cast est "souvent" signe d'une mauvaise conception, mais quelqu'un pourrait me montrer un cas où son utilisation est judicieux ?

(Sachant que l'inverse, non-const -> const, est implicite et là, je peux y voir un intérêt).

[Médinoc]

J'ai tendance à utiliser const_cast quand j'ai une classe de conteneurs avec un accesseur nécessitant des calculs ou une recherche, un truc du genre:

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
Contenu const & Conteneur::GetContenu(params) const
{
	//(recherche du bon contenu)
	return ret;
}
 
Contenu & Conteneur::GetContenu(params)
{
	Conteneur const * thisC = this;
	Contenu const & retC = thisC->GetContenu(params);
	return const_cast< Contenu & >(retC);
}

Dans le cas ci-dessus, je considère le const_cast "moins grave" que la duplication de code.

[gl]

Je sais que l'utilisation de const_cast est "souvent" signe d'une mauvaise conception, mais quelqu'un pourrait me montrer un cas où son utilisation est judicieux ?

Je vois essentiellement deux cas où l'usage d'un const_cast est nécessaire:

• Lorsqu'un objet constant doit être passer à une fonction d'une bibliothèque externe qui ne modifiera pas cette objet mais qui ne le qualifie pas de constant dans son prototype (donc pour contourner une incohérence dans le prototype d'une fonction).
• Pour contourner l'absence de "mutable" sans "déconstifier" certaines méthodes sur des compilateurs anciens.

[JulienDuSud]

J'ai tendance à utiliser const_cast quand j'ai une classe de conteneurs avec un accesseur nécessitant des calculs ou une recherche

Pourquoi ta 2ème méthode ne devrait pas être const ?
Pourquoi ne pas le faire en 3 méthodes claire ?

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
 
Contenu const & Conteneur::GetContenu(params) const
{
      return _GetContenu( params );
}
 
Contenu & Conteneur::GetContenu(params) const
{
      return _GetContenu( params );
}
 
Contenu & Conteneur::_GetContenu( params ) const
{
      // recherche
      return ret;
}

De plus, si tu permets l'accès en écriture, quelle est l'utilité d'avoir une méthode qui renvoi un objet const ? Sachant qu'un objet non-const est aussi une rvalue.

Si c'est pour l'usage privé de la classe, ou en héritage, _GetContenu n'est-il pas suffisant ?

Je vois essentiellement deux cas où l'usage d'un const_cast est nécessaire:

• Lorsqu'un objet constant doit être passer à une fonction d'une bibliothèque externe qui ne modifiera pas cette objet mais qui ne le qualifie pas de constant dans son prototype (donc pour contourner une incohérence dans le prototype d'une fonction).
• Pour contourner l'absence de "mutable" sans "déconstifier" certaines méthodes sur des compilateurs anciens.

Pour le 1er point, je ne qualifie pas ça d'une utilisation judicieuse, je qualifie ça de manque de rigueur de la part de la personne qui a développé la bibliothèque et donc d'un "bypass". C'est moche.

Pareil pour le 2ème argument... Si on a pas le choix du tout du compilateur, même passer à une version supérieur, à la limite...

Ce que je voulais dire, c'est... Quel est réellement le rôle de const_cast, si ce n'est pour contourner des problèmes... N'a-t-il pas un but précis, une situation où on ne peut pas faire sans dans la norme actuelle ?

[Médinoc]

Pourquoi ne pas le faire en 3 méthodes claire ?

Parce que la troisième méthode n'est pas toujours possible (par exemple, si l'on utilise un conteneur propageant la constance en tant que membre de la classe)

De plus, si tu permets l'accès en écriture, quelle est l'utilité d'avoir une méthode qui renvoi un objet const ?

La méthode qui renvoie un objet const est const. Celle qui renvoie un objet non-const est non-const. C'est un conteneur qui propage la constance.

[JulienDuSud]

Parce que la troisième méthode n'est pas toujours possible (par exemple, si l'on utilise un conteneur propageant la constance en tant que membre de la classe)

La méthode qui renvoie un objet const est const. Celle qui renvoie un objet non-const est non-const. C'est un conteneur qui propage la constance.

Je ne comprend pas très bien en quoi le fait que les 3 méthodes soient const empêche la propagation de constance, en fait
Au contraire, ça devrai l'accentuer, non ?

Je comprend pas trop l'intérêt d'avoir un Getter non-const...

[gl]

Pour le 1er point, je ne qualifie pas ça d'une utilisation judicieuse, je qualifie ça de manque de rigueur de la part de la personne qui a développé la bibliothèque et donc d'un "bypass". C'est moche.

Pareil pour le 2ème argument... Si on a pas le choix du tout du compilateur, même passer à une version supérieur, à la limite...

Oui, ce sont des contournements de problèmes (comme je l'avais d'ailleurs précisé). Toutefois ils ne sont pas ici signe d'une mauvaise conception dans notre code mais d'un souci dans un élément tiers (bibliothèque externe ou compilateur).

Ce n'est peut être pas "judicieux" comme usage, mais c'est souvent nécessaire (et généralement, beaucoup plus judicieux que d'enlever purement et simplement le qualificatif const dans notre code).

Ce que je voulais dire, c'est... Quel est réellement le rôle de const_cast, si ce n'est pour contourner des problèmes... N'a-t-il pas un but précis, une situation où on ne peut pas faire sans dans la norme actuelle ?

Mis à part quelque cas rares (comme celui proposé par Médinoc), le rôle de const_cast est essentiellement d'être compatible avec un existant peu rigoureux sur les const ou de contourner des problèmes de const trop restrictif.

[Médinoc]

Je ne comprend pas très bien en quoi le fait que les 3 méthodes soient const empêche la propagation de constance, en fait
Au contraire, ça devrai l'accentuer, non ?

Ben non, puisque ça permet de modifier un contenu alors que le conteneur est const --> La propagation de constance est rompue.

Je comprend pas trop l'intérêt d'avoir un Getter non-const...

C'est parce que ce getter retourne une référence non-const. C'est un truc à mi-chemin entre le getter et le setter, puisqu'il permet de modifier le contenu. Donc, il faut qu'il soit non-const.

Je suis constant que tous les conteneurs ne propagent pas la constance, et je suis également constant qu'on ne veut pas toujours que la constance soit propagée.
Mais quand on décide de propager la constance, il faut s'y tenir jusqu'au bout.