passage de paramètres : * et &

Bonjour à tous !

J'ai une petite question qui me trotte dans la tête depuis quelques temps, à savoir :

En C, j'ai souvent vu (et fait) des appels de fonctions où l'on passe un pointeur sur un "objet" en paramètre, pour pouvoir le modifier et éviter une grosse recopie, du genre :

Code:

---

void mafonction(mastructure1 *s)

---

Après une rapide formation en C++, le prof écrivait systématiquement ce genre de chose :

Code:

---

void mafonction(mastructure1 &s)

---

J'avais pendant le TP écris mes prototypes "à la C" avec * et il m'avait fait la remarque.

D'où mon interrogation (son explication de l'époque est passé à la trappe :oops: ).

En quoi est-ce différent ? Il y a une mécanique en jeu que je ne vois pas ? c'est une question de style ? de norme ?


Merci !

Bonjour,

un peu de lecture : Quand utiliser des références et quand utiliser des pointeurs

Et dans ce forum : [pointeurs/référence]

;)

Pour moi qui viens du C, ce serait plutôt "utiliser les pointeurs quand on le peut et les références quand il le faut" pour la raison déjà citée sur le code appelant, surtout sur les types primitifs (pour les structures, ça se rejoint).

En fait, il est extrêmement difficile de comprendre un code C++ utilisant du passage par référence sans que ces conditions soient toutes les deux réunies:

• Utiliser un environnement de développement qui donne le prototype d'une fonction
• Un strict respect de la const-correctness partout dans le code.

Car sans cela, il est impossible de savoir si:

Code:

---

1 2	int a=42; UneFonction(a);

---

Modifie a ou non. Et pour moi, le masquage d'informations est toujours un mal quand il s'agit d'informations sur quelque chose utilisé par le code appelant (ici, la variable a)

Citation:

---

Envoyé par gege2061

Bonjour,

un peu de lecture : Quand utiliser des références et quand utiliser des pointeurs

Et dans ce forum : [pointeurs/référence]

;)

---

Merci pour les liens, c'est vrai que j'aurais pu chercher un peu :oops:

Je crois avoir bien compris ;)

Cela a été discuté quantité d'autres fois. Je crois que j'avais déjà pondu une tartine sur le sujet.
Perso, les pointeurs bruts ne me plaisent pas car on ne sait jamais comment ils sont sensés être utilisés -> puit (sink) de donnée, donnée non effacable, donnée optionnelle, paramètre en sortie, ...

Je tombe plus souvent sur des codes aux pointeurs portant peu d'informations, que sur des codes avec des références qui ne sont pas utilisées de façon const-correcte.
Dans le premier cas, modifier le code pour rajouter plus d'infos est souvent complexe. Dans le second cas, c'est bête et méchant.

Citation:

---

Envoyé par médinoc

Car sans cela, il est impossible de savoir si:

Code:

---

1 2	int a=42; UneFonction(a);

---

---

Mais si.

Code:

---

1 2	const int a=42; UneFonction(a);

---

Je rejoins le point de vue de Médinoc même si il n'est pas orthodoxe.
L'exemple cité par Luc n'est pas déterminant de mon point de vue puisqu'il empèche, non pas une modification par Une Fonction, mais par TOUTES les fonctions

Code:

---

1 2	const int a=42; UneFonction(a);

---

D'autre part, il impose de retrouver et de revenir à la déclaration de l'argument pour comprendre la simple ligne

Code:

---

UneFonction(a);

---

Ce qui pour moi est un inconvénient majeur!

A quoi servent les références à part être un sucre syntaxique (qui évite d'écrire des *) ?
Conceptuellement, elles sont aussi complexes (sinon plus) à assimiler que les pointeurs. Elles en possèdent tous les inconvénients sans avoir leur seul (et pas négligeable) avantage (la possibilité de NULL). Leur définition classique (alias de ...) ne montre pas du tout le pourquoi de leur existence ni pourquoi on les utilise.
Toutefois, elles permettent quelque chose que les pointeurs ne permettent absolument pas : une fonction peut maintenant renvoyer un objet. Ceci est impossible avec les pointeurs. Leur intérêt n'est pas dans le passage des arguments, il est dans les possibilités de retour des fonctions.
Dans quel cas ceci est indispensable : pour la surcharge des opérateurs. Sans la surcharge des opérateurs, les références ne seraient qu'un gadget

Citation:

---

Envoyé par diogene

Elles en possèdent tous les inconvénients sans avoir leur seul (et pas négligeable) avantage (la possibilité de NULL).

---

On peut facilement renverser cet argument : a moins de ne pas lire les avertissements du compilateur, il est assez difficile de se retrouver avec une reference sur rien. Qui n'a jamais eu de bug alors qu'un pointeur se retrouvait sur une zone de memoire invalide ?

Citation:

---

Envoyé par diogene

Leur définition classique (alias de ...) ne montre pas du tout le pourquoi de leur existence ni pourquoi on les utilise.

---

Justement, si. On les utilise comme un moyen d'acceder a un objet deja existant.

Citation:

---

Envoyé par diogene

Toutefois, elles permettent quelque chose que les pointeurs ne permettent absolument pas : une fonction peut maintenant renvoyer un objet. Ceci est impossible avec les pointeurs.

---

On peut renvoyer un pointeur sur un objet, comme un objet lui meme. Que veux-tu dire exactement ?

Citation:

---

Envoyé par diogene

Sans la surcharge des opérateurs, les références ne seraient qu'un gadget

---

Dans la meme veine, la programmation en autre chose qu'en langage machine est un gadget : on ne gagne aucune fonctionnalite, juste une plus grande lisibilite. Et la lisibilite d'un code est a mon une des choses tres importante dans la mesure ou elle permet une maintenance plus facile. En reprenant un code ecrit par quelqu'un d'autre, je prefere largement lire des references que des pointeurs, ou l'on se demande a chaque fois qui a fait l'allocation et si la desallocation est faite correctement.

Sans la référence, on est bloqués entre la sémantique d'entité et les copies. Les opérateurs mathématiques n'en sont qu'un facette.

La référence présente pour moi deux intérêts (dans le passage d'arguments modifiables) : c'est non null, et non destructible. Avec un pointeur, on est vite tentés de faire n'importe quoi. Et du coup, on retire tous les fils pour savoir ce qu'il faut faire avec la donnée que que rares sont les docs qui précisent ce qu'il en est des responsabilités.

Après, le nom de la fonction et les noms des arguments se doivent de réfléter ce qui transite dans la fonction. Et dans quel sens. Je me pose bien plus rarement la question de savoir si le paramètre est entrant ou sortant, que de savoir comment est gérée sa vie.
Du coup j'évite les pointeurs bruts comme la peste et les références sont mes amies.


PS: aujourd'hui j'ai tendance à quasiment préfixer par "const" l'ensemble de mes variables dont l'état n'évolue pas après construction. Cela me facilite bien le reverse-engineering de relecture après quelques semaines.

Citation:

---

D'autre part, il impose de retrouver et de revenir à la déclaration de l'argument pour comprendre la simple ligne

---

Si tu ne retrouve pas tes données d'un coup d'oeil pour ne pas savoir si elles sont variables ou non au cours d'un traitement, alors quelque part, tes fonctions sont bien longues et les responsabilités de chaque donnée mal définies.

On préfère les références quand elles sont pertinentes exactement pour la même raison qu'on préfère un pointeur intelligent adapté à un pointeur
brut: les pointeurs bruts ont trop d'utilisations et utiliser autre chose de plus limité permet de signifier ce qu'on veut réellement, de faire vérifier une partie des contraintes statiquement par le compilateur et d'optenir une partie du comportement sans devoir mettre du code à chaque utilisation.

En particulier, les références en tant que paramètres permettent de dire à l'appelant: tu dois me donner réellement un objet et pas un pointeur nul et en contrepartie je te promets de ne pas prendre possession de l'objet (je ne le détruirai pas et il n'y aura pas d'accès après ma fin de vie -- retour de la fonction ou destruction de l'objet dans le cas des constructeurs, malheureusement il y a une ambiguité ici).

Si on veut une règle opérative plutôt que sémantique, on peut dire "il ne faut pas devoir utiliser l'opérateur &" mais elle est moins complète: dans

Code:

---

1 2 3 4 5 6 7 8 9 10

struct foo { foo(int&); ... };   foo* f() { int i; return new foo(i); }

---

mon explication montre que c'est peut-être une mauvaise idée (on passe une référence à un objet dont la durée de vie est plus longue que celle de la référence), alors que la règle opérative ne voit pas de problème.


Au fait, je suis guère convaincu par l'argument "on ne voit pas à l'appel les paramètres modifiés". D'une part C est plutôt une exception de ce point de vue -- qui peut m'en citer un qui ne soit ni un ancêtre direct, ni un descendant du C ? -- et si c'était important il y aurait plus de langages partageant cette caractéristique avec lui, d'autre part si on ne sait pas quels sont les paramètre susceptibles d'être modifiés, on sait tellement peu de choses sur la fonction que la première chose à faire, c'est de se renseigner.

Citation:

---

Envoyé par Jean-Marc.Bourguet

En particulier, les références en tant que paramètres permettent de dire à l'appelant: tu dois me donner réellement un objet et pas un pointeur nul et en contrepartie je te promets de ne pas prendre possession de l'objet (je ne le détruirai pas et il n'y aura pas d'accès après ma fin de vie -- retour de la fonction ou destruction de l'objet dans le cas des constructeurs, malheureusement il y a une ambiguité ici).

Si on veut une règle opérative plutôt que sémantique, on peut dire "il ne faut pas devoir utiliser l'opérateur &" mais elle est moins complète: dans

Code:

---

1 2 3 4 5 6 7 8 9 10

struct foo { foo(int&); ... };   foo* f() { int i; return new foo(i); }

---

mon explication montre que c'est peut-être une mauvaise idée (on passe une référence à un objet dont la durée de vie est plus longue que celle de la référence), alors que la règle opérative ne voit pas de problème.

---

Je n'ai pas bien compris ce deuxième paragraphe...

Si je reprend l'exemple du code, le constructeur d'une classe (foo) prend une référence en paramètre (qui est stockée dans une référence membre de la classe, je suppose). L'objet référencé (i) a une durée de vie plus courte que l'objet créé. Que se passera-t-il si on essaie d'accéder à i à partir de l'objet créé, après la fin de la fonction f() ? Est-ce que c'est un comportement indéterminé ?

Cela signifie qu'il ne faut pas utiliser les références en paramètre d'un constructeur (si on les stocke dans un membre de la classe) ? C'est bien ça ?

Merci d'avance !

Citation:

---

Envoyé par Eusebe

Si je reprend l'exemple du code, le constructeur d'une classe (foo) prend une référence en paramètre (qui est stockée dans une référence membre de la classe, je suppose).

---

On n'en sait rien quand on ne regarde que l'interface et c'est pour ça que j'ai écrit peut-être.

Citation:

---

L'objet référencé (i) a une durée de vie plus courte que l'objet créé. Que se passera-t-il si on essaie d'accéder à i à partir de l'objet créé, après la fin de la fonction f() ? Est-ce que c'est un comportement indéterminé ?

---

Gagné, on va vraissemblablement écraser une partie de la pile avec des effets désastreux.

Citation:

---

Cela signifie qu'il ne faut pas utiliser les références en paramètre d'un constructeur (si on les stocke dans un membre de la classe) ? C'est bien ça ?

---

Ça signifie que si on utilise les références avec le sens que j'ai donné (c'est pas obligatoire, j'ai ajouté du sens à ce qui est spécifié par la norme et d'autres peuvent avoir d'autres conventions), il ne faut pas passer de référence avec une durée de vie inférieure à l'objet. Ça ne me gène absolument pas que tu passes une référence à un mutex à une classe RAI instantiée sur la pile qui s'occupe de le libérer quand on la détruit (pour donner un cas plus réaliste qu'instancier foo sur la pile dans mon exemple).