Discussion :

[elvivo]

Bonjour,

Je me pose une question au sujet de la liberation de la memoire lors du dereferencement d'un pointeur retourne par une fonction.

J'ai la fonction suivante:

Code :

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

1
2
3
4
5
6
7
 
int* testFct()
{
    int* a = new int;
   *a = 42;
   return a;
}

Le main est:

Code :

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

1
2
3
4
5
6
7
8
9
 
int main()
{
    int b = 0;
 
    b = *testFct();
 
    return 0;
}

Mon probleme est: A quel moment je fais le delete?
Il me semble que la memoire a ete allouee mais dans la mesure ou je derefence le pointeur lors de l'appel de la fonction, je "perds" le pointeur.
J'espere aue j'ai ete clair
D'avance merci!

[Fredy Kruger]

Salut,

bien sur, tu as ete clair, voire meme pour etrangers :-))

Dans ton example ce n'est pas possible. Tu dois le faire comme ca :

Code :

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

1
2
3
4
5
6
7
8
9
 
int main()
{
    int *b = NULL;
 
    b = testFct();
 
    return 0;
}

En somme ... tu dois te souvenir le pointeur. La valeur est toujour accessible, mais en plus tu peux faire delete.

La recommandation - il faut TOUJOUR transmettre le pointeur :-))))))

Fredy "KRUGER"

[Davidbrcz]

Ou ne pas renvoyer de pointeur brut, c'est bien aussi surtout sur des types primitifs.

[elvivo]

@Davidbrcz: Oui c'etait juste un exemple. Dans la pratique je retournerai pas un pointeur sur un simple int sauf si j'ai une bonne raison

Merci a tous les deux!!
J'ai ma reponse.
A force d'utiliser des langages avec un garbage collector j'ai oublie les bons reflexes

[Davidbrcz]

Bah tu peux renvoyer des pointeurs intelligents (boost::shared_ptr ou équivalent) mais pas de pointeurs bruts.

[nikko34]

Oui le bon réflexe serait de ne pas utiliser de pointeurs bruts.:

Règle 1) Ne pas utiliser des pointeurs
Règle 2) Utiliser des références
Règle 3) Si vraiment besoin de pointeurs, ne pas utiliser de pointeurs bruts

[camboui]

Comment faire pour généraliser la règle 2) ?
Est-il possible de toujours se passer de (tout) pointeur quitte revoir la conception ?
En bref, comment corriger le code suivant en conservant la référence et en évitant le memory leak:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
int & testFct()
{
    int* a = new int;
   *a = 42;
   return *a;
}
 
int main()
{
    int b = 0;
     b = testFct();
     return 0;
}

[Goten]

C'est qu'un int ça se renvoie par copie ça :p.
Mais je suppose que tu voulais généraliser, ben y'a pas de méthode miracle.. passage en argument par référence? Ca peut être une solution, mais c'est pas ma préférée.
Sinon retourner par copie dans le cas d'un compilo qui fait du (N)RVO c'est ce qu'il y'a de plus efficace. Ou alors binder ta rvalue à une const ref... (mais c'est casse gueule si quelqu'un s'en sert autrement)

[gbdivers]

bonjour camboui

Je vais être moins catégorique que nikko34 : vouloir éviter à tout prix l'utilisation des pointeurs n'est pas forcement un bonne chose.

Pourquoi une référence plutôt qu'un pointeur : simplement parce que la référence garantie que l'objet existe. Donc pas besoin de vérifier l'allocation et pas de risque d'avoir un pointeur non null qui pointe vers rien (et provoquera une erreur à l'exécution).

Utiliser systématiquement un pointeur intelligent ? oui, sauf bonne raison de ne pas le faire

Une règle (recommandation ?) déjà lu quelque part : la classe qui crée un objet se charge aussi de la détruire.

Pour répondre à ta question (il faut bien y arriver un moment donné), lorsque la classe qui crée un objet continue d'existant pendant toute la vie de l'objet crée (par exemple un gestionnaire de fenêtre qui crée une fenêtre) alors tu peux retourner une référence. Si la classe est temporaire (ou que sa durée de vie n'est pas garantie), tu dois renvoyer un pointeur.

Dans ton code initial :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
int* testFct()
{
   int* a = new int; // tu crées un objet dynamique en mémoire et tu conserves l'adresse de cet objet dans "a"
   *a = 42; // tu affectes la valeur "42" à l'objet dynamique
   return a; // tu retourne l'adresse de l'objet dynamique
}

int main()
{
    int b = 0; // tu crées un objet statique
    b = *testFct(); // tu déréférences ton pointeur (tu vas chercher directement l'objet dynamique pointé) puis tu copies cet objet dans "b"
    return 0;
}

Ici, l'erreur provient du fait que tu recopies l'objet dynamique et ne conserve pas l'adresse de l'objet dynamique créé. Tu as donc 2 objets en mémoire : "b" qui est statique et accessible en utilisant la variable "b", et "a" qui est dynamique et qui n'est plus accessible (et ne peut donc être détruit : fuite mémoire).


Plein de méthodes pour éviter la fuite mémoire :
Avec un pointeur intelligent

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
typedef boost::shared_ptr<int> int_ptr;
 
int_ptr testFct()
{
   int_ptr a = new int_ptr();
   *a = 42;
   return a;
}
 
int main()
{
    int b = 0;
    b = *testFct();
    return 0;
}

Le pointeur intelligent "sait" qu'il existe plus de pointeur vers l'objet dynamique et le détruit automatiquement.


Retour par référence d'un objet interne à la fonction

Code :

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

1
2
3
4
5
int& testFct()
{
    int a = 42;
    return a; // retourne "a" par référence mais "a" est détruit en sortie de fonction : erreur !
}

Retour par copie de l'objet créé dans la fonction

Code :

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

1
2
3
4
5
int testFct()
{
    int a = 42;
    return a; // retourne une copie de "a" : ok !
}

Une classe créant un objet dynamique et se chargeant de le détruire :

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
class A
{
    A() { m_a=NULL; }
    ~A() { delete m_a; }
 
    int* testFct()
    {
        if(NULL==m_a) m_a = new int(42) else *m_a=42;
        return m_a;
    }
 
    private: int* m_a;
}
 
int main()
{
    A a();
    int b = 0;
    b = *testFct();
    return 0;
}

Classe utilisant un objet interne et renvoyant une référence (mieux que l'exemple de dessus) :

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
class A
{
    int& testFct()
    {
        m_a = 42; // plus besoin de test si NULL puisque existence garantie.
        return m_a;
    }
 
    private: int m_a;
}
 
int main()
{
    A a();
    int b = 0;
    b = testFct();
    return 0;
}

Une classe créant plusieurs objets dynamiques et se chargeant de les détruire :

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
class A
{
    typedef std::vector<int*> int_vector;
    typedef typename int_vector::iterator int_it;
 
    ~A() 
    {
        for(int_it it=m_vec.begin(); it!=vec.end(); ++it) delete (*it);
    }
 
    int* testFct()
    {
        int* a = new int(42);
        m_vec.push_back(a);
        return a;
    }
 
    private: std::vector<int*> m_vec;
}
 
int main()
{
    A a();
    int b = 0;
    b = *testFct();
    return 0;
}

J'espère avoir fait le tour et ne pas avoir dit trop de bêtises (d'autres se chargeront de me corriger )

[koala01]

Salut,

Il faut être prudent avec la règle 2...

Elle est vraie lorsque l'on parle de paramètres, ou lorsque l'on parle d'une fonction membre qui renvoie un membre de la classe /structure (bien que l'on préférera alors renvoyer une référence constante, pour éviter tout risque de modification "inoportune").

Par contre, il ne faut jamais renvoyer une référence sur un objet créé localement à une fonction, car l'objet sera détruit au moment où l'on quittera la portée de la fonction dans laquelle il est créé.

Le retour par valeur est donc la meilleure des solutions, sauf cas particuliers

bonjour camboui

Je vais être moins catégorique que nikko34 : vouloir éviter à tout prix l'utilisation des pointeurs n'est pas forcement un bonne chose.

En fait, il ne faut pas vouloir les éviter à tout prix, mais il faut les éviter "autant que faire se peut"...

Typiquement, il n'y a que de très rares cas dans lesquels des pointeurs seront réellement utiles, et toute la beauté de l'art réside dans le fait d'identifier avec certitude ces quelques cas

Pourquoi une référence plutôt qu'un pointeur : simplement parce que la référence garantie que l'objet existe. Donc pas besoin de vérifier l'allocation et pas de risque d'avoir un pointeur non null qui pointe vers rien (et provoquera une erreur à l'exécution).

c'est la raison technique la plus couremment citée...

Mais au delà, on peut également citer :

- le fait que l'on garde, avec les références, une syntaxe similaire à celle que l'on utiliserait si on avait affaire à un objet (plus besoin de se poser la question de savoir si on doit utiliser la fleche ou l'étoile pour accéder à un membre / une fonction membre)

- le fait que la constance est correctement tansmise avec les références, alors qu'il existe quatre possibilités de constance différentes avec les pointeurs (et que l'on risque donc de s'emmeler les pinceaux)

- Le fait que, si l'on commence à utiliser l'operateur address of, on risque facilement de se retrouver avec des pointeurs de pointeurs de pointeurs de ... et qu'il est très facile d'y perdre son latin

- Le fait que l'utilisation des pointeurs est souvent associée, dans la compréhension "populaire", au recours à l'allocation dynamique, et donc à tous les problèmes qu'elle peut engendrer.

Une règle (recommandation ?) déjà lu quelque part : la classe qui crée un objet se charge aussi de la détruire.

heuuu... oui, mais pas forcément...

Le problème auquel nous serons confrontés en respectant cette recommandation est que nous obtiendrons un couplage fort entre le contenant (la classe qui s'occupe de la création et de la destruction de l'objet) et le contenu (l'objet créé en ayant recours à l'allocation dynamique).

Dans bien des cas (en gros, chaque fois que le contenu sera polymorphe), il sera préférable d'avoir recours à une fabrique qui aura la responsabilité de créer un objet, et de laisser la responsabilité de la destruction au contenant.

Ce sera alors au contenant de s'occuper de la durée de vie du contenu, et il est possible de mettre en place (via les assertions ou les exceptions) un système qui renvoie une référence (constante ou non) sur le contenu uniquement s'il existe réellement