Discussion :

[damien77]

Bonjour,

J'aimerais avoir votre aide parce que je suis un peu perdu et je ne sais pas comment faire. En effet dans quel cas utiliser un pointeur ou une référence ?

Exemple dans le code suivant :

Code :

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

1
2
3
4
5
6
7
8
9
 
class Node
{
    public:
       Node *getParent() const;
       void setParent(const Node *);
   private:
       Node *parent ;
}

Nous utilisons les pointeurs. Mais serais-il possible d'utiliser les références ?...

merci de votre aide

[Luc Hermitte]

Non. Une référence est un alias qui ne peut être ré-attaché.

[damien77]

Peux tu donner un peu plus de détail. Ca ne m'aide pas beaucoup.

[koala01]

Salut,

En gros, un pointeur doit être utilisé, principalement, dans quatre circonstances:

• Quand tu veux pouvoir bénéficier du polymorphisme
• Quand une structure doit disposer de membre de son propre type (ou d'un type dérivé/parent).
• *éventuellement* quand un membre doit "survivre" à la classe qui le contient ou quand il doit pouvoir ne pas être initialisé... et que tu dois pouvoir tester s'il l'est ou non.
• Quand un argument passé en fonction peut ne pas exister (ce qui est tout à fait différent de "peut etre vide" )

En effet, il est impossible qu'un Noeud en contienne "physiquement" un autre... Tout ce qu'il peut contenir, c'est un rappel de l'adresse à laquelle il se trouve

Dans tous les cas, il s'agira de t'assurer que la libération de la mémoire allouée au pointeur soit correctement libérée au bon moment: ni trop tôt, ni trop tard

Si tu veux éviter la copie d'un élément, et que tu n'est pas dans l'un de ces quatre cas bien particulier, c'est donc une référence qu'il te faudra utiliser

Pour être précis: un pointeur est l'adresse à laquelle tu trouvera une variable du type donné, alors que la référence n'est qu'un alias (un autre nom) d'une instance donnée du type en question...

[ram-0000]

Je rajouterai une autre utilité

Dans un passage de paramètres à une fonction, une référence doit être utilisée lorsque cela n'a pas de sens que son équivalent pointeur soit NULL.

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
 
bool OpenFile(const string *Filename /*= NULL*/)
{
   if(Filename != NULL)
   {
      // open the file
      ...
   }
   else
   {
      // open stdin
      ...
   }
   ...
}

Dans ce cas, le fait que Filename soit NULL a un sens (pour ma fonction) donc je peux (et même je dois) utiliser un pointeur

[ac_wingless]

Peux tu donner un peu plus de détail. Ca ne m'aide pas beaucoup.

Le point crucial pour cette classe est bien celui qu'indique Luc hermitte: une référence est une sorte de pointeur constant dépointé. Il est donc impossible de changer vers quoi pointe la référence après sa création, ce qui élimine la possibilité d'implémenter le "parent" en tant que référence ET d'avoir une fonction setParent.
D'une manière générale, les références membres de classe sont à manipuler avec encore plus de précautions que les pointeurs membres. Certes, les pointeurs membres "nus" nécessitent en général la définition du destructeur, du constructeur de copie, et de l'opérateur d'affectation, ce qui n'est pas aussi simple d'utilisation que les boost::smart_ptr. Par contre, lorsqu'on a un membre référence, la sémantique de l'opérateur d'affectation va être très difficile à respecter (impossible de changer la référence après-coup), et il n'y a pas de constructeur par défaut automatiquement généré. Cela limite fortement les algorithmes génériques pouvant être appliqués à la classe, car ces deux opérations font très souvent partie des pré-requis des paramètres de classes génériques.

[screetch]

une reference indique une relation 1:1 avec une autre classe. c'est a dire que tu referencesune et une seule instance d'une autre classe ( tu la partage, tu ne la possedes pas ). De plus, tu ne peux pas changer l'objet que tu references.

les pointeurs sont souvent utilisés en relation 0:1 ou meme 0:n (comme une reference optionnelle, ou bien comme un tableau de 0 a n references). de plus cette reference vers une autre instance peut etre changée.

Si tu as une relation "forte" 1:1, alors tu devrais utiliser des references.

En résumé, reference =
-> pointeur faible (pas de partage de propriété)
-> non optionnel (tu dois des le debut pointer vers quelque chose)
-> impossible de "rebinder" sur autre chose

utiliser un pointeur (intelligent ou pas) si l'une de ces contraintes est relachée.

Tu peux verifier que pour les parametres de fonction c'est exactement le cas :
-> pointeur faile (tu ne possedes pas le parametre, c'est l'appelant qui le possede)
-> non optionnel (tu dois toujours passer un parametre ou bien le parametre par defaut)
-> non rebindable : tu ne peux plus, une fois dans la fonction, revenir en arriere pour passer j au lieu de i

[koala01]

Je rajouterai une autre utilité

Dans un passage de paramètres à une fonction, une référence doit être utilisée lorsque cela n'a pas de sens que son équivalent pointeur soit NULL.

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
 
bool OpenFile(const string *Filename /*= NULL*/)
{
   if(Filename != NULL)
   {
      // open the file
      ...
   }
   else
   {
      // open stdin
      ...
   }
   ...
}

Dans ce cas, le fait que Filename soit NULL a un sens (pour ma fonction) donc je peux (et même je dois) utiliser un pointeur

Non, car tu pourrais très bien vérifier si la chaine est vide (ou non), et, en tout cas, la passer en tant que référence, idéalement constante

Je suis d'accord avec le fait qu'un argument qui peut ne pas exister sera fourni sous la forme d'un pointeur, vallant NULL s'il n'existe effectivement pas, ce qui se rapproche du troisième cas cité (allez, je vais rajouter le cas des arguments )

Mais on déconseille fortement de fournir un pointeur sur tout ce qui vient de la S(T)L:

std::string, conteneurs flux et, d'ailleurs l'ensemble de la S(T)L sont à fournir "par principe" et de préférence en tant que référence, constante s'il échoit

[Médinoc]

Si le code fait une différence entre une string vide et pas de string du tout, alors là c'est bien un pointeur qu'il faudra utiliser, par contre...

[koala01]

Si le code fait une différence entre une string vide et pas de string du tout, alors là c'est bien un pointeur qu'il faudra utiliser, par contre...

Oui, mais tel que présenté ici, le code ne permet pas de déterminer s'il fait effectivement une telle distinction...

En plus, le code pourrait très bien s'appliquer, en l'occurrence, avec une chaine vide

[damien77]

D'accord donc pour résumer dans ce cas là.

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
 
class RNode
{
    public:
        void setParent(const Node &);
    private:
        Node parent ;
}
 
class PNode
{
    public:
        void setParent(const Node *);
    private:
        Node *parent ;
}

La référence permet de manipuler l'objet original au moment de l'appel de la fonction mais par la suite nous avons une copie...

La node permet de manipuler et stocker l'adresse mémoire de notre objet.

[MatRem]

Tu peux aussi très bien stocker un pointeur vers l'objet en passant par une référence dans la fonction.

Code :

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

1
2
3
4
5
6
7
class Node
{
public:
   void setParent(Node const & parent);
private:
   Node const * _parent ;
}

[Médinoc]

Mais je trouve ça crade au possible.

Et ça nuit à la lisibilité du code. Un code pareil, je le rejette.

[nikko34]

comme un Node peut ne pas avoir de parents, tu n'as pas trop le choix, tu ne peux pas utiliser de références.

[Emmanuel Deloget]

Tu peux aussi très bien stocker un pointeur vers l'objet en passant par une référence dans la fonction.

Code :

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

1
2
3
4
5
6
7
class Node
{
public:
   void setParent(Node const & parent);
private:
   Node const * _parent ;
}

C'est excessivement risqué, puisque ça permet de passer à la fonction setParent() un instance locale à une fonction de manière implicite - c'est à dire sans que le programmeur ait à reflechir à ce qu'il fait. Si il a l'obligation de rajouter l'opérateur &, il voit de suite qu'il passe en paramètre l'adresse d'un objet automatique, et il se pose la question de la légalité de ce qu'il écrit.

Un semblant de règle :

1. si l'objet doit avoir une durée de vie qui n'est pas automatique : utiliser un pointeur
2. si la référence sur un objet peut être invalide : utiliser un pointeur (pour comparaison avec NULL)
3. si la référence sur un objet peut varier pendant l'exécution du programme : utiliser un pointeur.
4. dans le cas contraire : une référence peut probablement faire l'affaire.

[loufoque]

si la référence sur un objet peut être invalide : utiliser un pointeur (pour comparaison avec NULL)

Ou pas. Utiliser un bit particulier ou rajouter un booléen marche aussi, et est plus performant car tu n'es pas obligé d'allouer ton objet dynamiquement comme cela est nécessaire dans certains cas.

[screetch]

ca ne change rien a l'allocation, une reference ne te permettra pas de changer une alloc dynamique en alloc statique par magie.

[loufoque]

Tu fais un POD de la taille et de l'alignement de ton type, et tu rajoutes un booléen pour indiquer si il est initialisé ou pas.
Quand tu veux construire ton élément, tu fais un placement new sur l'adresse de ton POD et tu mets le booléen à vrai.
Dans le destructeur, si le booléen vaut vrai tu appelles le destructeur de ton type.

C'est comme ça qu'est implémenté boost.optional.

[screetch]

une reference n'est pas du tout pareille. la, tu es l'unique proprietaire de l'objet. une reference, tu n'es meme pas l'un des proprietaires.

dans l'exemple precedent, il faudra m'expliquer comment tu peux stocker ton parent a l'interieur de toi meme dans un pod...

[doccpu]

Ou pas. Utiliser un bit particulier ou rajouter un booléen marche aussi, et est plus performant car tu n'es pas obligé d'allouer ton objet dynamiquement comme cela est nécessaire dans certains cas.

Erreur : une référence sur un NULL est impossible donc si l'on passe un pointeur NULL à une méthode qui attend une référence ça bug a tous les coups !