Discussion :

[Dani3L]

Bonjour

J'essaie de prendre de plus en plus l'habitude d'utiliser des références au lieu de pointeur dans mes codes C++. Ce n'est pas facile car jusqu'à maintenant, j'ai beaucoup utilisé de pointeurs et changer les habitudes n'est pas évident.

J'ai lu l'article "Pointeurs vs Références" dans la FAQ mais je n'arrive pas vraiment à comprendre dans la pratique où on utilise des références et où on utilise des pointeurs.

Je me posais par exemple la question suivante. Si dans une fonction on crée un objet, on est obligé de le faire dynamiquement (avec new) si l'on souhaite que la durée de vie de l'objet continue après l'exécution de la fonction.

J'imaginais donc la syntaxe suivante pour cette fonction si l'on souhaite créer (par exemple) une matrice dans la fonction et avoir en retour une référence vers cette matrice (au lieu d'un pointeur) :

Code :

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

1
2
3
4
5
6
 
Matrix & function()
{
    Matrix * mat = new Matrix(3,5);
    return (*mat);
}

Je voulais donc savoir si ce genre de truc était vraiment utilisé ou pas ? Je voulais aussi savoir si c'était fréquent d'avoir des référence en retour de fonction ?

Si vous avez quelques conseils concernant l'utlisation de références à la place de pointeurs, n'hesitez pas.

Merci d'avance de vos réponse.

[Médinoc]

Ah, non, on ne fait jamais ça!
D'ailleurs, ma première réaction face à un tel code ressemblerait à cela :

Tout new implique un delete. On ne fait pas de delete sur une référence...

Par contre, on peut retourner un pointeur intelligent, qui lui serait un objet. Personnellement, j'ai tendance à préférer le comptage de références intrusif, mais il cause parfois des problèmes de const-correctness...

[Dani3L]

Ah, non, on ne fait jamais ça!
D'ailleurs, ma première réaction face à un tel code ressemblerait à cela :

Tout new implique un delete. On ne fait pas de delete sur une référence...

Ah effectivement je n'avais pas pensé à cela. Merci beaucoup pour ta réponse.

[Sylvain Togni]

Mais en fait on fera plutôt ça

Code :

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

1
2
3
4
Matrix function()
{
    return Matrix(3,5);
}

[koala01]

Salut,

De prime abord, on décidera d'utiliser les référence chaque fois qu'un pointeur n'est pas indispensable.

En gros, les pointeurs ne sont indispensables que dans deux cas particuliers:

• quand tu as des références "cycliques":quand le contenu doit avoir une référence sur le contenant (ou cas similaires) ou quand un objet de type A qui contient un objet de type B, qui contient un objet de type C, qui contient un objet... de type A (ou, au plus simple: un objet de type A qui contient un objet de type... A)
• Quand tu veux disposer du polymorphisme: tu dispose deux classes filles qui dérivent d'une même classe mère, et tu veux pouvoir faire cohabiter des instances des trois types dans un même conteneur (en les faisant passer pour des instance de la classe mère)

D'un autre côté, on ne renverra une référence que si l'on a l'absolue certitude que la variable renvoyée continuera à exister en dehors de la méthode qui la renvoie.

Ainsi, il est tout à fait possible de prévoir un code proche de

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
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
class A
{
    public:
        A(const B& b):b(b){}
        A():b(){}
        ~A(){}
        /* const */ std::string& foo()
        {
            return b.theString();// OK: B::c existe tant que b existe, et
                                 // lui même continuera à exister tant que
                                 // l'instance de A existera
        }
        /* const */ B& getB()
        {
            return b; //ok... b continue à exister tant que l'instance de A
                      // existe
        }
        /*const*/ std::string& autreString(const std::string& p)
        {
            std::string str="salut "+p;
            return str; // NOK: str est détruite en sortie de fonction
        }
        /* par contre, ceci irait (mais couterait une copie de la chaine...
         * et c'est logique: on n'utilise pas de référence
         */
        /* const */ std::string foo(const std::string& p)
        {
            std::string str="salut "+p;
            return str;
        }
    private:
        B b;
};
class B
{
    public:
        B(const std::string& c=""):c(c){}
        ~B(){}
        /*const */ std::string& theString(){return c;}
    private:
        std::string c;
};

[Mat007]

Salut,

Ah, non, on ne fait jamais ça!
D'ailleurs, ma première réaction face à un tel code ressemblerait à cela :

Tout new implique un delete. On ne fait pas de delete sur une référence...

Je pense que le code suivant est valide :

Code :

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

delete &function();

Ça va à l'encontre des conventions généralement observées, c'est sûr, mais à part ça je ne vois a priori rien qui l'interdise.

MAT.

[Mat007]

D'un autre côté, on ne renverra une référence que si l'on a l'absolue certitude que la variable renvoyée continuera à exister en dehors de la méthode qui la renvoie.

En même temps pour un pointeur aussi, hein...

MAT.

[koala01]

En même temps pour un pointeur aussi, hein...

MAT.

Oui, bien sur, mais d'un autre coté, si le pointeur pointe vers une instance (non membre) allouée dynamiquement, il y a moins de risque que la destruction de l'instance à partir de laquelle a été invoquée la méthode qui a effectué l'allocation dynamique provoque la libération de la mémoire et donc la destruction de l'instance pointée par le pointeur

[EDIT]c'est pas clair du tout, ca... je reviendrai quand j'aurai trouvé le moyen de l'exprimer plus aisément

[loufoque]

En gros, les pointeurs ne sont indispensables que dans deux cas particuliers:

* quand tu as des références "cycliques":quand le contenu doit avoir une référence sur le contenant (ou cas similaires) ou quand un objet de type A qui contient un objet de type B, qui contient un objet de type C, qui contient un objet... de type A (ou, au plus simple: un objet de type A qui contient un objet de type... A)
* Quand tu veux disposer du polymorphisme: tu dispose deux classes filles qui dérivent d'une même classe mère, et tu veux pouvoir faire cohabiter des instances des trois types dans un même conteneur (en les faisant passer pour des instance de la classe mère)

Aucun de ces deux cas ne nécessite de pointeurs. En fait, rien ne nécessite d'utiliser des pointeurs où que ce soit.
Bien entendu, je parle de l'interface des "briques". Pour faire certaines briques (structures de données, pimpl idiom, dynamic dispatch) il faut bien entendu des pointeurs, mais il peut s'agir uniquement de détails d'implémentation.

[Dani3L]

Mais en fait on fera plutôt ça

Code :

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

1
2
3
4
Matrix function()
{
    return Matrix(3,5);
}

Je n'arrives pas vraiment à comprendre à quoi correspond cette syntaxe.

Est-ce que cela revient au même que :

Code :

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

1
2
3
4
5
6
7
 
Matrix function()
{
    Matrix mat(3,5);
    ....
    return mat;
}

[Médinoc]

Oui, mais cela engendre une copie, puisque que l'objet est retourné par valeur (même s'il y a les optimisations RVO et NRVO).

De plus, il n'est plus question ici de polymorphisme, qui n'est possible que via référence ou pointeur...

[Dani3L]

Si par exemple je fais ceci :

Code :

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

1
2
3
4
5
6
7
8
 
template <typename T>
inline Matrix<T> operator + (Matrix<T> & matrix1, Matrix<T> & matrix2)
{
    Matrix<T> sumMatrix(matrix1.getNbRow(), matrix1.getNbColumn());
    ...
    return sumMatrix;
}

est-ce que ceci parait juste ?

car lorsque j'essaie d'afficher ma matrice résultat de la façon suivante (je ne sais pas du tout si c'est juste de manipuler le retour de ma fonction opérateur de cette façon) :

Code :

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

1
2
 
(matrix1+matrix2).display();

le programme plante.

[loufoque]

C'est probablement parce que tu as mal redéfini ton constructeur de copie.