Discussion :

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

Code :

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

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 :

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

int * fonction_debile

... pourrais je utiliser la fonction comme lvalue?

Merci, a+

[Arzar]

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.

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

Ben essaye

Code :

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

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;
}

[FabTheGeek]

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+

[Arzar]

http://codepad.org/0pgj40Oa

[FabTheGeek]

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+

[koala01]

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

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

[metagoto]

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

[koala01]

Et bien pour moi, c'est tout à fait l'inverse.
Une référence constante est un pléonasme
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;

[Lavock]

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 :

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

 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.

[metagoto]

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

[koala01]

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:

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