Discussion :

[Mathusalem]

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 :

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

void mafonction(mastructure1 *s)

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

Code :

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

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

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 !

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

[Médinoc]

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 :

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

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)

[Mathusalem]

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

Je crois avoir bien compris

[Luc Hermitte]

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.

Car sans cela, il est impossible de savoir si:

Code :

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

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

Mais si.

Code :

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

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

[diogene]

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 :

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

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 :

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

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

[roulious]

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 ?

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.

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 ?

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.