Transmission d'une ref sur const dans une fonction

Bonjour à tous,

une petite question concernant la transmission d'arguments par référence dans les fonctions.

Code:

---

1 2	int f(const int& r) { }

---

nécessite-il forcément que la variable transmise soit un int constant? Ou est ce juste une sémantique spéciale pour dire que la variable, bien que passée par ref ne sera pas modifiée?

Merci

bonjour,

le const n'est pas obligé, il s'agit juste d'un attribut sémantique qui dit à celui qui va utiliser: "tu peux être sûr que cette variable ne sera pas modifiée".


Sinon quelques remarques:

Dans le cas d'un type natif, le passage par référence constante ne change absolument rien au passage par valeur.

On peut lire parfois que le passage par référence constante aide le compilateur à optimiser dans le cas d'un type complexe. C'est faux. Le compilateur ne peut pas optimiser à cause de l'existence du mot clé mutable.

Mais on est bien d'accord que

Code:

---

const int& a

---

signifie : déclarer pour argument une référence vers un int constant ? Et non une référence constante (redondance ;) )vers un int? N'est ce pas?

A moins que le mécanisme de déclaration de variable et celui d'argument ne fonctionnent pas de la même façon...

Oui c'est une référence sur constante. (et par abus de langage on parle de référence constante).
le const s'applique toujours à ce qui le précéde sauf si il y'a rien avant il s'applique à ce qui est juste après.
ie :
const T& == T const &


(beaucoup préfèrent la seconde écriture afin d'éviter ce genre d'ambiguïté.)

donc mettons que

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

int a=2; int b;   int main() {   b=g(a); return 1; }   int g(const int& x) { }

---

dans le premier appel je dis bien x pointe vers a qui n'est pourtant pas constant... et je devrais donc avoir une erreur non?

Non, ce que ça veut dire c'est que dans la fonction tu ne pourras pas modifier x (et donc pas a, vu que x n'est qu'un alias pour a).

Hola,

mais const int& x veut bien dire que ce que pointe x est une constante non? et non pas que x est une reference constante (ce qui est redondant puisque je crois savoir qu'une reference est tjs const).

a+

Citation:

---

Envoyé par FabTheGeek

mais const int& x veut bien dire que ce que pointe x est une constante non?

---

Pour être précis, const int & x, en paramètre d'un fonction f(), signifie juste que dans la portée de la fonction f(), x ne peut pas être modifié. En fait, il y a un const_cast caché (mais qui ne coûte rien puisque ça ne concerne que la compilation).

Citation:

---

Envoyé par FabTheGeek

je crois savoir qu'une reference est tjs const.

---

Non, certainement pas! Tu devrais lire attentivement la FAQ sur les références :)

Hola,

ben justement à en croire ton lien:

Citation:

---

Comment faire pour modifier une référence de façon qu'elle désigne un autre objet ?
[haut]
auteur : Marshall Cline
Ce n'est pas possible.

On ne peut pas séparer le référé de sa référence.

Contrairement aux pointeurs, lorsqu'une référence est liée à un objet, elle ne peut pas être réaffectée à un autre objet. La référence en elle-même n'est pas un objet (elle n'a pas d'identité : prendre l'adresse d'une référence retourne l'adresse du référent).

De ce point de vue, une référence est similaire à un pointeur constant

int* const p

par opposition à un pointeur sur une constante

const int* p

En dépit d'une certaine ressemblance, ne confondez pas les références et les pointeurs ; ce n'est pas du tout la même chose.

---

une référence pourrait bien être assimilé à un pointeur constant. C'est ce que je voulais dire, maintenant effectivement l'objet pointé ne l'est pas forcément.

Seulement ce qui me gêne c'est le "const" de la variable pointée...
On est bien d'accord que const int& x signifie: x est une reference à un int constant ?
Si cela est vrai comment il est possible que:

Code:

---

1 2	int a=2; const int& x= a;

---

soit accepté?

Citation:

---

Envoyé par Goten

Oui c'est une référence sur constante. (et par abus de langage on parle de référence constante).

---

Je ne suis pas trop d'accord avec ça. Dans:

Code:

---

void f(const int & a)

---

c'est la référence sur a qui est constante. La variable pointée par a, on ne sait pas si elle est contante.

Citation:

---

Envoyé par FabTheGeek

ben justement à en croire ton lien:

une référence pourrait bien être assimilé à un pointeur constant. C'est ce que je voulais dire, maintenant effectivement l'objet pointé ne l'est pas forcément.

---

Que dit la FAQ?

Citation:

---

Envoyé par Marshall cline

De ce point de vue, une référence est similaire à un pointeur constant

---

De ce point de vue, c'est à dire que dans le sens où l'on ne peut pas modifier l'objet pointé par la référence. De ce point de vue oui, c'est comparable, mais sinon c'est très différent.

Il faut bien comprendre qu'un pointeur c'est un objet, et une référence c'est l'adresse d'un objet. Une référence n'est pas un objet, mais la syntaxe est la même, ce qui porte à confusion (chose qui est fréquemment critiquée d'ailleurs, notamment par les programmeurs qui viennent du C).

Un pointeur est un objet qui contient l'adresse de l'objet pointé. Cette encapsulation permet de définir des fonctionalités aux pointeurs (comme pour n'importe quel objet). C'est ce qui permet ce que l'on appelle l'arithmétique de pointeur. Si on a un pointeur p, on peut faire p+1, p-1, p++, etc. Ces opérateurs ('-', '+', ´--', '++', etc.) sont définis de la même façon que l'on définit des opérateurs dans nos propres classes. Ceci est impossible à faire pour une référence car une référence n'est pas un objet.

Citation:

---

Envoyé par FabTheGeek

On est bien d'accord que const int& x signifie: x est une reference à un int constant ?

---

Comme je l'ai dit plus haut, je ne suis pas d'accord avec ça. Moi je dirais: x est une référence constante sur un objet de type entier. C'est la référence qui est constante, par l'objet pointé.

x est une référence (constante dans le sens ou on ne peut pas "rebinder" une référence) read-only (c'est a dire, const en termes C++) sur une variable.
La variable peut changer en dehors de la fonction; dans ce cas la nouvelle valeur sera mise a jour lorsqu'on utilise la référence.

cela signifie simplement que cet acces a la variable sera read-only quoi.

Citation:

---

Envoyé par r0d

Comme je l'ai dit plus haut, je ne suis pas d'accord avec ça. Moi je dirais: x est une référence constante sur un objet de type entier. C'est la référence qui est constante, par l'objet pointé.

---

Mais une référence est constante par définition, on ne peut pas modifier l'objet pointé, par contre je suis d'accord que la valeur, elle est modifiable. Et c'est la que je ne comprend pas le const int& x en argument puisqu'on ne peut pas imposer à la variable référencé d'être constante!

Je ne comprends pas ce que tu veux dire par

Citation:

---

Envoyé par FabTheGeek

on ne peut pas modifier l'objet pointé, par contre [...] la valeur, elle est modifiable.

---

on ne peut pas changer d'avis sur l'objet sur lequel on veut pointer
la valeur de l'objet peut être changée par un autre moyen par contre

Code:

---

1 2 3 4 5 6 7 8 9

void doWeirdStuff(const int& original, int& out) { printf("%d\n", original); out = 2; // original etait marqué const mais maintenant il a changé... printf("%d\n", original); } int a = 0; doWeirdStuff(a, a);

---

Citation:

---

Envoyé par FabTheGeek

Et c'est la que je ne comprend pas le const int& x en argument puisqu'on ne peut pas imposer à la variable référencé d'être constante!

---

Pourquoi est-ce qu'on ne pourrait pas ?

Je récapitule les règles de bind entre référence et référé :

Code:

---

1 2 3 4 5

ref const ref lvalue #1 Oui #2 Oui const lvalue #3 Non #4 Oui rvalue #5 Non #6 Oui

---

Ce qui donne en code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

void ref(int&){} void cref(const int&){}   int main() { void ref(int&){} void cref(const int&){}   int main() { int i = 1; //lvalue const int j = 2; // const lvalue   ref(i); // #1 cref(j); // #2 // ref(j); // #3 //error C2664: 'ref' : cannot convert parameter 1 from 'const int' to 'int &' cref(j); //#4 // ref(5); // #5 rvalue // error C2664: 'ref' : cannot convert parameter 1 from 'int' to 'int &' cref(6); //#6 rvalue }

---

Les régles de bind ont été conçu pour authoriser une flexibilité maximale tout en évitant les catastrophes. Dans le cas qui te préoccupe (#2), on est tout à fait autorisé à rajouter une contrainte : dans la fonction la référence sera constante, donc on ne pourra pas modifier l'objet référé, même s'il n'est pas const à la base.

Par contre, dans un cas comme #3 c'est interdit. Ça serait trop dangereux d'autoriser à modifier la référence dans la fonction alors que l'objet référé est const ! Pareil pour le cas #5 : ça n'a pas beaucoup de sens de vouloir modifier une rvalue. Dans le code que j'ai donné plus haut, la rvalue est le nombre "5". C'est une variable temporaire, qui n'a pas de nom et pas d'adresse, donc on ne peut pas la modifier, ce qui est bien reflété dans les règles de bind.

Edit : sinon, je suis d'accord avec rOd, ça ne me dérange pas de parler de référence constante, même si c'est peut être un très léger abus de langage. En fait la différence fondamentale entre un pointeur et une référence c'est qu'une référence n'est pas rebindable.

Citation:

---

Envoyé par Arzar

Pourquoi est-ce qu'on ne pourrait pas ?

---

parce que quelqu'un d'autre pourrait la modifier.

Personne ne peut modifier une référence constante vu qu'elle est ... constante !
J'ai l'impression qu'on ne parle pas de la même chose. :fou:

cf mon code un peu plus haut...

Code:

---

1 2 3 4 5 6 7 8 9

void doWeirdStuff(const int& original, int& out) { printf("%d\n", original); out = 2; // original etait marqué const mais maintenant il a changé... printf("%d\n", original); } int a = 0; doWeirdStuff(a, a);

---

Comme je l'ai dit au début amha c'est un problème de terminologie... vous utilisez (on) pas les mêmes termes pour désigner la même chose

c'est pour ca que pour la compréhension du texte il serait bon de remplacer const par "read-only".

Hola,

je deterre le topic pour parler cette fois des références en retour de fonction.

J'ai donc appris depuis qu'une référence en retour d'une fonction permettait de faire de jolies choses notamment d'utiliser un appel de fonction comme lvalue:

Code:

---

1 2 3 4 5 6

int a=2; int & fonction_debile(int & w) { return w; } fonction_debile(a)=3;

---

Malgré l'intérêt de mon code, l'idée est élégante.

La question, est ce que la même chose est possible avec un pointeur?
Si je fais un truc du genre

Code:

---

int * fonction_debile

---

... pourrais je utiliser la fonction comme lvalue?

Merci, a+

Citation:

---

Envoyé par FabTheGeek

Hola,

je deterre le topic pour parler cette fois des références en retour de fonction.

J'ai donc appris depuis qu'une référence en retour d'une fonction permettait de faire de jolies choses notamment d'utiliser un appel de fonction comme lvalue:

---

Oui, par exemple l'opérateur[] de la classe vector repose sur ce comportement.

Citation:

---

La question, est ce que la même chose est possible avec un pointeur?

---

Ben essaye :D

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

#include <iostream>   int* foo(int* i) { return i; }   int main() { int i = 4; *(foo(&i)) = 3; std::cout << i; }

---

;)

je suis au boulot et n'ai pas accès à un compilateur digne de ce nom ;)
Si tu ne veux pas que je meure étouffé par la curiosité et l'impatience il va falloir me le dévoiler ;)

a+

http://codepad.org/0pgj40Oa :mrgreen:

Merci ;)

plus ca va, moins j'ai envie de m'encombrer l esprit avec deux concepts différents (pointeurs et references), mais ça doit être l'effet débutant ;)

a+

Salut,

Concernant la compréhension des références, j'aime bien les comparer à des alias...

En effet, l'alias d'une personne ne s'applique, dans un contexte donné, qu'à une personne bien déterminée et, si la teigne de la cité est un dénommé Lucien Bazar, dit "le gros lulu", vous savez, lorsque vous entendez que "le gros lulu a encore fait des siennes" que l'on ne parle pas de Lucien Bidule qui est le bon gars le plus sympathique de ce coté de la grand route...

Pourtant, il n'y a pas à s'y tromper: c'est bien Lucien Bazar qui a fait des siennes :D

Quand on y pense, une référence agit exactement de manière similaire ;)

Là dessus, vient se greffer le problème du mot clé const... et, au delà, celui de la portée des variables.

Comme l'a si bien fait valoir r0d, le mot clé const est un attribut purement sémantique qui indique "je m'engage à ne pas modifier l'objet que je fournis", et qui demande au compilateur de veiller à ce que cet engagement soit respecté dans toute la portée dans laquelle la référence sur l'objet est accessible.

Ainsi, lorsque l'on déclare comme argument d'une fonction une référence constante (car c'est quand même le vocable généralement utilisé), cela veut simplement dire qu'il n'y aura aucune tentative de modifier l'objet entre l'accolade ouvrante et l'accolade fermante de la fonction, indépendamment du fait que l'objet soit constant ou non en dehors de celle-ci.

Maintenant, sur le fait d'utiliser le vocable "référence constante" ou "référence sur objet constant", je dirais volontiers que l'on assiste ici à une "querelle de clocher", chacun voyant midi à sa porte...

Après tout, lorsque l'on dit que le gros lulu a fait des siennes, "gros lulu" n'ayant aucune existence légale (seul Lucien Bazar est connu de l'état civil), il y a littéralement association entre les deux noms, l'un et l'autre pouvant, dans leurs contextes respectifs, être utilisés indifféremment pour représenter la même personne...

Ceci dit, je serais plus proche de l'idée d'utiliser le terme référence constante pour la simple raison que le vocable "référence sur objet constant" risque, justement, de donner la fausse impression que l'objet qui est passé en argument est constant à la base (comprenez: qu'il est constant dans la fonction appelante), alors qu'il ne prend la sémantique de constance que pour la durée de l'exécution de la fonction à laquelle il est passé comme paramètre.

Il faut, enfin, se rappeler que le mot clé constant a un effet particulier dans le sens où il ajoute des restrictions quant aux actions que l'on peut entreprendre sur l'objet déclaré constant:

En effet, lorsque le type de l'objet est une classe, seules les fonctions membres déclarées constantes (donc prenant, elles-aussi, l'engagement de ne pas modifier l'objet sur lequel elles agissent) pourront être utilisées.

Mais cela n'empêche nullement d'appeler une fonction membre constante au départ d'un objet qui... ne l'est pas ;)

Citation:

---

Envoyé par koala01

Ceci dit, je serais plus proche de l'idée d'utiliser le terme référence constante pour la simple raison que le vocable "référence sur objet constant" risque, justement, de donner la fausse impression que l'objet qui est passé en argument est constant à la base (comprenez: qu'il est constant dans la fonction appelante), alors qu'il ne prend la sémantique de constance que pour la durée de l'exécution de la fonction à laquelle il est passé comme paramètre

---

Et bien pour moi, c'est tout à fait l'inverse.
Une référence constante est un pléonasme :mrgreen:
Par nature ref équivaut à const ref. Ce qui n'est pas la même chose que ref to const.
Par analogie aux pointers, une ref est une sorte de const pointer. Un ref to const serait un const pointer to const

Citation:

---

Envoyé par metagoto

Et bien pour moi, c'est tout à fait l'inverse.
Une référence constante est un pléonasme :mrgreen:
Par nature ref équivaut à const ref. Ce qui n'est pas la même chose que ref to const.
Par analogie aux pointers, une ref est une sorte de const pointer. Un ref to const serait un const pointer to const

---

Je dirais que c'est parce que tu fais l'association référence == pointeur constant...

Or, justement, j'explique que, de mon point de vue, une référence n'a "pas grand chose à voir" avec les pointeurs, mais qu'elle est plutôt associée à un alias.

Il est tout à fait vrai que, du point de vue du code généré, une référence va agir exactement comme un pointeur constant, mais la comparaison s'arrête là, alors qu'elle va, finalement, plus loin lorsque l'on se dit que référence == alias de l'objet:

Du pur point de vue de la syntaxe à mettre en œuvre, un pointeur diffère de l'objet pointé parce que l'on doit utiliser la flèche "->" ou l'étoile pour pouvoir accéder à son contenu, alors que l'on peut utiliser une référence exactement de la même manière et avec la même syntaxe que l'objet référencé (modulo les restrictions dues à l'ajout de constance éventuel).

[EDIT]Ceci dit, j'ai l'impression qu'il suffirait surtout se mettre d'accord sur la définition à donner au terme "référence" pour que nous tombions rapidement d'accord sur la manière de parler d'un T const & ref= truc; :P

Tout le problème de l'ambiguïté du terme référence en c++... Pour rester dans l'esprit du langage (abstraction), je suis plutôt du côté de koala01.

Après tout, faisons fît de l'implémentation tant qu'on garde en mémoire que cela n'améliore pas (ou très rarement peu (et même peut-être jamais par rapport a un pointeur constant)) les performances...

Pour répondre à l'intéresser, on va dire que c'est l'effet débutant direct c++... Un pointeur est sémentiquement plus simple qu'une référence étrangement... Malheureusement, je crains le débat enflammé si je continue...

Personnellement, je dirai que ton problème se situe plus sur les lval/rval. (moi aussi j'ai des problème, je me souviens jamais lequel est lequel, pb de latéralité oO)

En gros, (pensez à foutre ça dans la faq), on distingue de type de donné : les lvalue, qui possèdent une adresse, sont affectables, et non-momentané, et le rvalue, le reste.

A ça, on rajoute const. On a donc 4 types d'entité possible.

Le monde du C était très simple, jusqu'à ce que Strtsprt (<-boutade) veuille faire des références... Les références qui ne sont que des raccourcis passant par les pointeur, donc nécessite que la valeur est une adresse. C'est à dire, une lvalue. Note que les références sont justement des [const] lvalue.

Présentons le cas suivant :

Code:

---

Fct(sousFct());

---

sousFct() désigne bien une rvalue temporaire ici... mais qu'en est-il dans sousFct() ? patatra, c'est la fin de notre jolie petit monde en noir et blanc, si jamais sousFct pèse 2 tonnes, obligé de le copier (alors que les deux copies vont disparaitre à la fin de la ligne oO).

Et là, Strouprutroupsprut (<-oui je boute beaucoup aujourd'hui)dit : "Noooo Waaay"... C'est l'apparition du bind.

Pour bien comprendre comment ça marche, j'énoncerai les règles de bind (masquage ou abstraction) :
lvalue => ref || const ref
const lvalue => const ref
[const] rvalue => const ref (qui devient donc une const lvalue).

Et bientôt, le comité c++0x arriva >< ! Un Anonyme du forum (je ne vise personne, suivez mon regard) et ces nombreux collègues se sont dit : tiens, mais c'est dommage ça qu'on ne puissent pas modifier cette vieille valeur temporaire que tout le monde s'en fout qu'on la trucide (et plein d'autre problématique encore) !
Et là, un fou c'est levé dans l'assemblé, et à dits : mais pourquoi pas faire des ravlue référence ! (/marone dans l'assemblé).

Et voilà que c'est petite merveille sont apparue, nous permetant tant bien que mal de transformé des rvalue en lvalue (sans toutefois allongé la porté de vie). Bref, la famille se rallonge, et les règle de bind devienne un peu compliqué... sans parler des templates, des référence de référence... ça fait plusieurs page à expliquer... Bref, si tu es un débutant masochiste : Draft sur les rvalue référence.

Citation:

---

Envoyé par koala01

Je dirais que c'est parce que tu fais l'association référence == pointeur constant...

---

En fait, non pas du tout, d'ailleurs je parle d'analogie.
Je rebondissais sur ta préférence envers la dénomination "référence constante" plutôt que "référence sur objet constant".

La deuxième proposition me parait bien meilleur car une référence est toujours constante par nature. C'est ref to [const] qui importe, et non [const] ref. Dans ce deuxième cas, le const est implicitement et automatiquement appliqué.

Citation:

---

Envoyé par metagoto

En fait, non pas du tout, d'ailleurs je parle d'analogie.
Je rebondissais sur ta préférence envers la dénomination "référence constante" plutôt que "référence sur objet constant".

La deuxième proposition me parait bien meilleur car une référence est toujours constante par nature. C'est ref to [const] qui importe, et non [const] ref. Dans ce deuxième cas, le const est implicitement et automatiquement appliqué.

---

Je suis d'accord avec toi sur le fait que, par nature, la référence est constante dans le sens où, effectivement, nous ne pouvons pas changer l'objet référencé.

En cela, tu as raison de dire que la notion de constance d'une référence est intrinsèque au concept lui-même.

Mais ce n'est pas *forcément* une raison pour estimer que le fait de parler de "référence constante" soit un pléonasme, simplement parce que, c'est peut être sous entendu, mais ca s'applique... à l'objet référencé dans le sens où il ne peut pas être modifié et non dans le sens où on ne peut pas changer d'objet référencé en cours de route.

De plus, j'ai la conviction que le fait de parler de référence constante au lieu de parler de référence sur un objet constant est largement de nature à éviter la confusion qui a mené à la question initiale:

Citation:

---

nécessite-il forcément que la variable transmise soit un int constant?

---