Conversions de type constants

Version imprimable

21/08/2009, 13h22
blanchonvincent

Conversions de type constants
Bonjour,

J'ai lu dans un livre que :
Code:

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 ?
21/08/2009, 14h16
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 :aie:

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:

const_cast<float> pi = 4;

ni même

Code:

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:

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 :aie:

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 ;)
21/08/2009, 14h30
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:

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 ?

Citation:

Envoyé par Koala01

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

Koala, avec VS2005, ce code :
Code:

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.

21/08/2009, 14h37
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" ?
21/08/2009, 14h53
koala01
Citation:

Envoyé par Arzar

Koala, avec VS2005, ce code :

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

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 :D
Code:

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.

Citation:

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

Il semblerait en effet :D

@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é :question:

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 :D
21/08/2009, 14h59
blanchonvincent

Très bien merci j'ai compris !
21/08/2009, 16h05
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.
21/08/2009, 16h06
Goten
Euh :
Code:

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?
21/08/2009, 16h32
Arzar

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

Et ça compile avec VS2005 et affiche 4. Je suis aussi surpris que toi.
21/08/2009, 16h34
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.
21/08/2009, 18h02
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...
23/08/2009, 09h14
JulienDuSud
Ce sujet m'intrigue...

Parce que, imaginons ce code:
Code:

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

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:

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.

23/08/2009, 12h04
gl
Citation:

Envoyé par JulienDuSud

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.

Citation:

Envoyé par 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

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

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 ?

Citation:

Envoyé par gl

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 ?

23/08/2009, 12h29
Médinoc

Citation:

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)

Citation:

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.
23/08/2009, 13h02
JulienDuSud

Citation:

Envoyé par Médinoc

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 :D
Au contraire, ça devrai l'accentuer, non ?

Je comprend pas trop l'intérêt d'avoir un Getter non-const...
23/08/2009, 13h26
gl

Citation:

Envoyé par JulienDuSud

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

Citation:

Envoyé par JulienDuSud

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.
23/08/2009, 15h04
Médinoc

Citation:

Envoyé par JulienDuSud

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 :D
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.

Citation:

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.