Discussion :

[diogene]

r0d Pour ergoter un peu :

Je ne suis pas d'accord. Une référence, c'est l'adresse de l'endroit où est stocké l'objet. Un pointeur est une variable dans laquelle est stockée l'adresse où est stocké l'objet. Ce n'est pas du tout la même chose.

Passé en argument d'une fonction, l'argument "pointeur" est l'adresse où est stocké l'objet. C'est devenu une simple valeur, pas une variable. Je préfère pour ma part dire que la référence est l'objet.

Lorsque tu passes un pointeur en paramètre, ce pointeur est copié lors de l'appel à la fonction. Donc si tu modifie le pointeur à l'intérieur de la fonction, il y a de grandes chances pour que cela engendre des problèmes.

Et pourquoi donc ?

L'utilisation d'une référence fait gagner un adressage par rapport à un pointeur.

???

Par exemple, la fonction suivante

Code :

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

1
2
3
4
void foo(const int* p)
{
	*p+=5;
}

compile,

Ne compile pas

[Médinoc]

Passé en argument d'une fonction, l'argument "pointeur" est l'adresse où est stocké l'objet. C'est devenu une simple valeur, pas une variable. Je préfère pour ma part dire que la référence est l'objet.

C'est quand même plus compliqué. Quand on se met à jouer avec les pointeurs (notamment "prendre l'adresse d'une référence"), on prend l'adresse de l'objet en effet. Pour moi, je préfère dire que la référence est un pointeur déguisé, et que chaque utilisation comporte une étoile implicite (cad, int *pi = &ri correspond à int *pi = &*pr_i.

Et pourquoi donc ?

Sans doute, parce que ceux qui connaissent mal les pointeurs les confondent avec les références...

???

Dans le source. La référence masque un niveau d'indirection par rapport au pointeur (mais ne fait que le masquer, évidemment).

Ne compile pas

En effet. Par contre, ce code-ci compile, du fait des priorités opératoires:

Code :

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

1
2
3
4
void foo(const int* p)
{
	*p++;
}

Naturellement, il ne fait pas la même chose (en l'ocurrence, ce code ne fait rien).

[r0d]

Pour ergoter un peu :
Passé en argument d'une fonction, l'argument "pointeur" est l'adresse où est stocké l'objet. C'est devenu une simple valeur, pas une variable. Je préfère pour ma part dire que la référence est l'objet.

Peut-être n'ais-je pas bien compris ce que tu voulais dire, mais je soutiens qu'un pointeur, qu'il soit passé en argument de fonction ou non, est une variable. Si tel n'était pas le cas, aucune arythmétique ne serait applicable aux pointeurs.

Les pointeurs sont justement des variables qui contiennent l'adresse d'autres objets[...]

(http://c.developpez.com/tutcpp/x1541.php)

Et pourquoi donc ?

Parce que, justement, un pointeur est une variable, ce qui induit donc une indirection supplémentaire. En revanche, et je m'en doutais un peu, ce point semble être négligeable:

En lui-même le niveau d'indirection supplémentaire est de la gnognotte

(http://jlecomte.ifrance.com/c++/c++-...antics-fr.html )

Ne compile pas

Hum oui, désolé, je me suis trompé Erreur de copier/coller
Je voulais dire:

void foo( const int* p)
{
p+=5; // pas de déréférencement
}

[diogene]

Peut-être n'ais-je pas bien compris ce que tu voulais dire, mais je soutiens qu'un pointeur, qu'il soit passé en argument de fonction ou non, est une variable.

Ce que je veux dire c'est que les arguments d'une fonction (hormis les références) sont dans un contexte de valeur.
Dans le cas d'un pointeur qui nous occupe, je peux mettre
- une adresse (NULL, &objet,...)
- ou un pointeur et dans ce cas, celui-ci est interprété comme la valeur du pointeur, autrement dit l'adresse de l'objet pointé (ou NULL)
- ou une expression (genre p+1) qui évaluée fournit elle aussi une valeur de type adresse de... (Dans p+1, p est aussi dans un contexte de valeur)

Christian Casteyde a écrit :
Les pointeurs sont justement des variables qui contiennent l'adresse d'autres objets[...]

Entièrement d'accord

Parce que, justement, un pointeur est une variable, ce qui induit donc une indirection supplémentaire.

Entièrement pas d'accord pour une référence en argument de fonction. C'est vrai si on reste dans le code où la référence est définie puisqu'alors le compilateur sait quel objet correspond à la référence (mais ce n'est pas très utile). Mais en passage d'argument, le seul moyen d'identifier l'objet dans la fonction est de connaître son adresse et c'est ce qui est passé à la fonction.

[Médinoc]

diogene a raison, il n'y a aucune différence d'indirection entre:

Code :

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

1
2
3
4
5
6
7
8
9
10
void UneFonction(UneClasse &obj)
{
	obj.uneFonctionNonVirtuelle();
}
 
void UneAutreFonction()
{
	UneClasse unObjet;
	UneFonction(unObjet);
}

et:

Code :

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

1
2
3
4
5
6
7
8
9
10
void UneFonction(UneClasse *pObj)
{
	pObj->uneFonctionNonVirtuelle();
}
 
void UneAutreFonction()
{
	UneClasse unObjet;
	UneFonction(&unObjet);
}

[diogene]

Médinoc

C'est quand même plus compliqué. Quand on se met à jouer avec les pointeurs (notamment "prendre l'adresse d'une référence"), on prend l'adresse de l'objet en effet. Pour moi, je préfère dire que la référence est un pointeur déguisé, et que chaque utilisation comporte une étoile implicite (cad, int *pi = &ri correspond à int *pi = &*pr_i.

C'est une autre manière de dire la même chose : Si la référence est un pointeur (déguisé) déréférencé par une étoile (implicite) c'est qu'elle désigne l'objet dont l'adresse correspond au pointeur (déguisé).
Accessoirement, j'ai toujours trouvé incohérente la définition des références par
int &p
au lieu de
int *& p qui seraitcohérent avec int * pi = &p
On retrouve encore ton étoile implicite