Retourner un pointeur

Version imprimable

Voir 40 message(s) de cette discussion en une page

Suite a ma question existentielle ici, je ne vois pas
pourquoi ceci en C++ ?

Example 65 Dangerous memory management

Code:

1
2
3
4
5
6
7
8
9
 
String myFunc( const char* myArgument )
   {
       String* temp = new String( myArgument );
       return *temp;
       // temp is never deallocated and the user of myFunc
       // cannot deallocate because a temporary copy of
       // that instance is returned.
   }

Que faire alors ?

21/09/2008, 23h36
Frifron

Je ne dirais meme pas que c'est une gestion de la mémoire dangereuse mais tout simplement que c'est un exemple qui présente une fuite mémoire. Car tu retournes en effet une copie de la string dynamiquement alloué dans la fonction. Cette copie n'a pas la même adresse (elle est sur la pile). Tu perds donc l'adresse de la string originale allouée dynamiquement sur le tas et tu ne pourra jamais la libérer -> conséquence : de la mémoire perdue a chaque appelle de la fonction.

Pour éviter cela, il faut retourner un pointeur, mais c'est a utiliser délicatement également car la c'est une gestion de la mémoire pontentiellement dangereuse car l'utilisateur doit alors désallouer de la mémoire qu'il n'a pas lui même alloué. Bref il faut savoir ce qu'on fait.

Mais la bonne méthode est de ne pas allouer la mémoire dynamiquement.

Quand tu dis que faire ? C'est dans quel sens ? En regle général il faut éviter au maximum l'allocation dynamique.

Code:

1 2 3 4 String myFunc( const char* myArgument ) { return String(myArgument); }
Tout simplement.
Le C++ c'est pas du Java, on met pas des new partout.

22/09/2008, 01h03
@Ikey
Pour répondre à ta question il faut rappeller les bases de l'utilisation d'un pointeur:
Code:

1 2 3 4 5 6 ... Bar *pFoo = new Bar; // Alloue un espace mémoire ... delete pFoo; // Libère l'espace mémoire pFoo = 0; // Pour plus de sécurité, mais non indispensable ...
Or dans ta fonction tu ne peux pas faire de "delete temp". Par conséquent, l'espace mémoire ne sera libérée qu'à la fin de l'exécution du programme.

Ensuite, je me pose la question de l'utilité d'une telle pratique. Il faut vraiment avoir l'esprit tordu.
Contrairement au titre de ton sujet, la fonction "myFunc" ne retourne pas un pointeur (plutôt l'adresse vers laquelle pointe le pointeur), mais la valeur vers laquelle pointe l'adresse contenu dans "temp".

En gros c'est la même chose, en beaucoup moins bien que:
Code:

1 2 const char myArgument = 'a'; String foo (myArgument);
Quoiqu'il en soit, en C++ on n'utilise essentiellement les références.
On utilisera un pointeur uniquement si on ne peut pas faire autrement, ce qui est très rare.

Pour le reste Frifron a répondu. Si tu veux pouvoir faire un delete sur le pointeur, il faut que la fonction "le retourne", mais c'est vraiment une très mauvaise pratique.

Si je dois résumer. Le principe à appliquer est simple.

Citation:

Une fonction qui déclare un pointeur doit obligatoirement le détruire.

@Ikey
22/09/2008, 10h11
mailaka
Merci pour ces premieres precisions.

L'exemple que j'ai pris etait un exemple tire d'une liste de recommandations. Mais ils se rapprochait de ma question existentielle version C++.

Disons que ca ne soit pas un String (qui est deja tres evolue) mais juste un tableau d'entiers. Je sais aussi que tout compte fait, mieux vaudrait passer par un vector et laisser a vector tous ces details sanglants.

Mais pour aller au fond des choses, supposons que je veux fournir a un utilisateur un tableau des n premiers nombres entiers ..
Code:

1 2 3 4 5 6 7 8 int * AllocateAndPopulatePrimes(const int n){ int *temp= new int[n]; //// ici je remplis temp return temp; }
Ou sont les pb ?
22/09/2008, 10h21
mailaka

Citation:

Envoyé par Frifron

Je ne dirais meme pas que c'est une gestion de la mémoire dangereuse mais tout simplement que c'est un exemple qui présente une fuite mémoire. Car tu retournes en effet une copie de la string dynamiquement alloué dans la fonction. Cette copie n'a pas la même adresse (elle est sur la pile). Tu perds donc l'adresse de la string originale allouée dynamiquement sur le tas et tu ne pourra jamais la libérer -> conséquence : de la mémoire perdue a chaque appelle de la fonction.

Excuse-moi, qui est sur le tas et qui est sur la pile ?
22/09/2008, 10h27
Médinoc
Citation:
Envoyé par mailaka

Mais pour aller au fond des choses, supposons que je veux fournir a un utilisateur un tableau des n premiers nombres entiers ..

Code:

1 2 3 4 5 6 7 8 int * AllocateAndPopulatePrimes(const int n){ int *temp= new int[n]; //// ici je remplis temp return temp; }

Ou sont les pb ?
Ici, il n'y a aucun problème. Il y en aurait un si le tableau était directement une variable locale, mais c'est impossible car n n'est pas une constante connue à la compilation.
22/09/2008, 14h10
@Ikey
Citation:
Envoyé par mailaka

Merci pour ces premieres precisions.

L'exemple que j'ai pris etait un exemple tire d'une liste de recommandations. Mais ils se rapprochait de ma question existentielle version C++.

Disons que ca ne soit pas un String (qui est deja tres evolue) mais juste un tableau d'entiers. Je sais aussi que tout compte fait, mieux vaudrait passer par un vector et laisser a vector tous ces details sanglants.

Mais pour aller au fond des choses, supposons que je veux fournir a un utilisateur un tableau des n premiers nombres entiers ..

Code:

1 2 3 4 5 6 7 8 int * AllocateAndPopulatePrimes(const int n){ int *temp= new int[n]; //// ici je remplis temp return temp; }

Ou sont les pb ?
J'ai déjà répondu à la question:

Citation:

Envoyé par @Ikey

Une fonction qui déclare un pointeur doit obligatoirement le détruire.

Or là tu déclares le pointeur "temp" et tu laisses à qui le récupère la tache de le détruire! [Pas bien!!]

;)

@Ikey
22/09/2008, 14h42
Médinoc

@@Ikey: J'espère que c'est une plaisanterie. :roll:
22/09/2008, 14h52
@Ikey

Citation:

Envoyé par Médinoc

@@Ikey: J'espère que c'est une plaisanterie. :roll:

Autant pour moi, je me suis très mal exprimé. :oops: Le pointeur est biensûr détruit à la fin de la méthode.
Je voulais parler de l'espace mémoire allouée à "int[n];" dans le free store qui n'est pas libéré.

@Ikey
22/09/2008, 15h48
Médinoc

Et en plus il est sérieux...8O

Leçon du jour: Les fonctions retournant un pointeur vers une mémoire nouvellement allouée.

C'est une façon très courante de retourner un tableau. La fonction alloue le tableau avec new[], et la responsabilité de sa suppression revient à la fonction appelante, qui doit faire un delete[] une fois que la mémoire allouée n'est plus nécessaire.
En C++, il est conseillé d'utiliser des pointeurs intelligents (comme des auto_ptr<>, ou les shared_ptr<> de Boost) afin d'éviter les fuites de mémoire si la fonction appelante oublie de désallouer.
22/09/2008, 16h21
Sylvain Togni

Citation:

Envoyé par Médinoc

C'est une façon très courante de retourner un tableau.

En C, peut-être, pas en C++.

Citation:

En C++, il est conseillé d'utiliser des pointeurs intelligents (comme des auto_ptr<>, ou les shared_ptr<> de Boost) afin d'éviter les fuites de mémoire si la fonction appelante oublie de désallouer.

Il est surtout conseillé de ne pas utiliser new[] au profit, notamment, de std::vector.
22/09/2008, 16h44
Médinoc

Ça dépend des besoins en performance, car toutes les implémentations de vector ne font pas de copy-on-write. Dupliquer tout le vecteur n'est pas toujours la meilleure solution...
22/09/2008, 20h46
loufoque

Où est-ce que tu dupliques un vecteur ?
(Aucune implémentation ne fait de COW sur les vecteurs à ma connaissance)
23/09/2008, 09h08
Médinoc

Très simple: Si tu retournes un vecteur par valeur, son constructeur de copie est appelé (sauf peut-être en cas de RVO).

Mais j'ai un meilleur exemple de fonction retournant un pointeur nouvellement alloué: Le pattern Factory...
Ou celui de la méthode clone()...
23/09/2008, 10h32
Frifron

Mais on n'a pas dit qu'il ne fallait jamais utiliser de fonction allouant de la mémoire et retournant le pointeur. On a juste dit qu'il fallait l'utiliser en faisant attention car cause possible de fuite mémoire. Et que très souvent l'allocation statique peut être utilisé de facon beacoup plus sûre et performante.
23/09/2008, 15h14
mailaka

Ok, je pense que l'utilisation de vector est conseillee generalement. Pour le deuxieme exemple de mon cru, effectivement, ca laisse la responsabilite de la release de la memoire a l'utilisateur de la fonction. Mais bon, c'est la vie :mrgreen:

Sinon, comment se passerait l'utilisation de pointeur intelligent pour alleger la memoire .. oops le travail de l'utilisateur ? Quand utiliser auto_ptr<> au lieu de shared_ptr<> ?

PS1 : Frifron, pourrais-tu mieux expliciter ton premier post, stp ? Je ne vois pas tres bien ou se situe la fuite memoire en fait sur l'exemple en string.

PS2 : Medinoc, c'est quoi un RVO ?
23/09/2008, 15h39
Médinoc

Pour auto_ptr<>, je ne sais pas trop, je dois avouer que je ne l'utilise jamais... :oops:

La fuite mémoire du premier post: Tu alloues une String sur le tas, mais tu retournes par valeur une copie de cette String. Quand la fonction a retourné, la String sur le tas existe toujours, mais tu n'as plus aucun pointeur pour y accéder ou la détruire --> Fuite.

RVO et NRVO : (Named) Return Value Optimization.
23/09/2008, 15h56
mailaka

Citation:

Envoyé par Médinoc

Pour auto_ptr<>, je ne sais pas trop, je dois avouer que je ne l'utilise jamais... :oops:

La fuite mémoire du premier post: Tu alloues une String sur le tas, mais tu retournes par valeur une copie de cette String. Quand la fonction a retourné, la String sur le tas existe toujours, mais tu n'as plus aucun pointeur pour y accéder ou la détruire --> Fuite.

Je crois que je suis perdu entre les tas et les piles .. carte .. non GPS bienvenu !

Ok, par contre je vois le pb quand dans cet exemple, le return *temp renvoie non l'objet alloue precedemment mais une autre copie.

Citation:

RVO et NRVO : (Named) Return Value Optimization.

C'est malin, l'acronyme ! Mais encore ? :aie:

Pour la fuite mémoire c'est simple : à chaque new doit correspondre un delete. Tu fait appel à un new mais à aucun delete => fuite mémoire.

En ce qui concerne std::auto_ptr<> c'est un pointeur intelligent conçu pour maintenir un seul propriétaire à un objet :
Code:

1 2 3 std::auto_ptr<Objet> p1(new Objet); // p1 est LE propriétaire de l'objet std::auto_ptr<Objet> p2 = p1; // transfère de propriété : maintenant c'est p2 qui est LE propriètaire assert(p2.get() == NULL); // et p1 a été mis à NULL
Les boost::shared_ptr<> servent au contraire à partage un objet entre plusieurs propriétaires :
Code:

1 2 3 boost::shared_ptr<Objet> p1(new Objet); // p1 est UN propriétaire de l'objet boost::shared_ptr<Objet> p2 = p1; // p2 est UN autre propriètaire de l'objet assert(p1 == p2); // p1 et p2 pointent sur le même objet
L'objet est détruit automatiquement lorsqu'il n'a plus de propriétaire.

Pour NRVO, google doit être ton meilleur ami.

Voir 40 message(s) de cette discussion en une page