Discussion :

[deubelte]

Bonjour
Il me semble qu'il y a aucune différence entre int et int&.
Par exemple, ces deux fonctions sont identiques:

Code :

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

1
2
3
void f(int o); 
et
void f(int&o);

En gros, pour les types primaires, cela ne sert à rien de passer une variable par référence ou par valeur.
(Donc autant ne faire passer que des int).
Idem pour cette fonction:

Code :

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

1
2
int f(void);
int& f(void);

Mais je ne me rappelle plus pourquoi.

Merci

[3DArchi]

int et int& sont 2 types radicalement différents. Le premier est un entier, le second est une référence vers un entier. Le comportement n'est pas le même :

Code :

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

1
2
3
4
5
6
7
f(int&);
int main()
{
   int i=0;
   f(i);//ok
   f(3);// erreur
}

Code :

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

1
2
3
4
5
6
7
f(int );
int main()
{
   int i=0;
   f(i);//ok
   f(3);// ok
}

Code :

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

1
2
3
4
5
6
7
8
9
10
f(int&o)
{
   ++o;
}
int main()
{
   int i=0;
   f(i);//ok
   assert(1==i);
}

Code :

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

1
2
3
4
5
6
7
8
9
10
f(int o)
{
   ++o;
}
int main()
{
   int i=0;
   f(i);//ok
   assert(0==i);
}

Quand à la valeur retour :
int f(); retourne une valeur par copie
int& f(); retourne une référence. L'objet a intérêt d'exister après le retour de la fonction et tant que la référence est liée. Sinon, undefined behaviour (dans ce cas, c'est souvent un plantage).

Cette question indique la nécessité de se replonger dans les premiers cours pour débutant.

[deubelte]

je me doute bien que si on a :

int f(int&) et qu'on fait f(4), ca va planter.

mais moi, je me restreint au cas où:

Code :

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

1
2
3
int f(int& a)
{...
}

Code :

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

1
2
3
 
int a=4;
f(a)

et

Code :

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

1
2
3
int f(int a)
{...
}

Code :

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

1
2
3
 
int a=4;
f(a)

sont, ils me semblent identiques, dans l'appel de la fonction f.

[screetch]

bah non, comme 3darchi l'a pointé:

Code :

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

1
2
3
4
5
6
7
8
9
10
f(int o)
{
   ++o;
}
int main()
{
   int i=0;
   f(i);//ok
   assert(0==i);
}

Code :

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

1
2
3
4
5
6
7
8
9
10
f(int&o)
{
   ++o;
}
int main()
{
   int i=0;
   f(i);//ok
   assert(1==i);
}

[deubelte]

oui, mais ce que je voulais dire, c'est que quand tu fais f(Obj o), tu appelles le constructeur par copie, ici, non: f(Obj &o) alors que pour un type primaire, f(int o) ou f(int &o) c'est la même chose, pas d'appel au constructeur par copie.

Vous voyez?

[screetch]

tout s'eclaire si tu dis const int& au lieu de int&pour un entier, non, ca ne change pas grand chose, souvent les compilateurs passent ca dans les registres si ils peuvent.
Pour un type plus complexe effectivement, sans passer des références const, ca fait une copie, ce qui est chiant (vas y que je te copie une list ou un vector...)

[deubelte]

oui, je suis allé trop vite!
-pourquoi est il nécessaire de préciser const?

pour moi, une fonction peut renvoyer une ref sur une variable locale de type int, ca ne pose pas de pb.
Ensuite, pour un objet, oui, ca pose problème, et j'en ai déjà vu.

[screetch]

préciser const revient presque au même qu'envoyer une copie mais coûte moins cher.

Mettons que tu veuilles donner un objet en paramètre a une fonction, tu n'as pas envie que ta version soit modifiée. Sit u passes juste une référence, la méthode que tu appelles a le droit de bidouiller ton objet comme elle veut.
Si tu ne veux pas "perdre" ton objet, tu peux soit passer une copie (coûteux) soit passer une référence, pour aller plus vite, mais _const_ pour empêcher la méthode que tu appelles de modifier l'objet.
Si elle souhaite modifier, elle fera elle même une copie.


Renvoyer une référence sur un entier local, peut être ca ne crashera pas mais personne ne sait quelle valeur aura ton entier.
que penses-tu que ce code va faire?

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
20
#include <cstdio>
 
int& f(int x)
{
    int y = x;
    return y;
}
 
int& g(int x)
{
    int y = x*2;
    return y;
}
 
int main()
{
    int& x = f(3);
    int& y = g(3);
    printf("%d\n", x);
}

[deubelte]

que penses-tu que ce code va faire?

Je viens de regarder, en Release, avec le plus d'optim possible, ca donne 3 puis 6.

[screetch]

que veux tu dire "3 puis 6"? il n'y a qu'un seul printf

[deubelte]

Pardon, ca donne 3
J'avais mis deux print.

[screetch]

ah bon
chez moi, ca compile pas.
quand je demande au compilateur de la fermer, et que je lance le programme, ca affiche 6.
chez toi ca affiche 3
chez mon voisin, ca a éteint les lumières de sa cuisine.

Autant dire que ca marche pas vraiment

[deubelte]

Tu as quoi comme compilateur? Moi VC2010.

[screetch]

moi GCC sous windows. Et GCC est assez sympa pour me prévenir que ca ne marchera pas
Ca ne peut pas marcher; tu as une référence sur un temporaire. Lorsque tu quittes la fonction, le compilateur est libre de réutiliser l'espace pour autre chose, ce qu'il ne se gènera pas pour faire.
même sous VC2010 je parie que je peux avoir plusieurs comportements différents. par exemple si tu le fais tourner en debug, il va te dire que x vaut -572662307.

[deubelte]

va te dire que x vaut -572662307.

6
Monsieur!
La je suis convaincu.

[Flob90]

Pour la nécessité du const pour faire des références sur des objets temporaires, c'était un problème si par exemple on voulait pouvoir modifier le paramètre, pas le choix de mettre void foo(T&); mais dans ce cas un appel du genre foo(0); ne marchais pas, c'est "corrigé" dans le C++2011 avec les rref. (cf C++Next pour une série d'articles sur le sujet)

Et en effet on dit souvent que pour les types fondamentales l'interet de passer par des références constantes est faible (dans un contexte ou l'on peut choisir l'un ou l'autre), mais ca ne fait pas pour autant la même chose. La raison pour laquelle l'interet est faible c'est que dans ce cas créer une référence ou copier le type ont le même coût.