Retourner un pointeur

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 ?

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.

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

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 ?

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 ?

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.

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

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

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

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.

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.

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

Où est-ce que tu dupliques un vecteur ?
(Aucune implémentation ne fait de COW sur les vecteurs à ma connaissance)

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

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.

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 ?

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.

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.

Citation:

---

Envoyé par Sylvain Togni

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.

---

Et c'est surtout que tu n'as plus la possibilité de faire un delete sur la string. Car la string retournée est une copie de celle créée dynamiquement avec new.

Il y a donc 2 objets string : celle retournée et celle créer dynamiquement dans la fonction. Ce sont 2 objet différents, leurs adresses ne sont pas identique : &returnedString != temp. Tu perds donc l'adresse de la string allouée dynamiquement, la mémoire ne pourra plus être libérée dans le programme puisque tu n'a plus de pointeur pointant sur l'objet dynamique pour faire un delete dessus.

Tu m'as l'air un peu perdu. Je me permet de résumé un poil les réponses.

Citation:

---

Envoyé par mailaka

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 ?

---

En bref: Ta fonction crée un tableau sur le tas. La responsabilité de ce tableau est transférée au client (en gros, c'est de la responsabilité de celui qui appelle cette fonction de veiller à ce que la mémoire allouée dans ta fonction soit bien desallouée).
Dans beaucoup d'articles ou de livres on qualifierais ta fonction de "source" (notamment les articles expliquant les auto_ptr).

Il y a 2 problèmes distincts avec ce code:
1) Le client de ta fonction ne sait pas a priori quel est le bon opérateur delete à appliquer afin de désallouer le tableau.
2) Il y a une fuite mémoire potentielle si l'appelant décide de ne pas gérer le pointeur envoyé.

Illustration du point 1:
--
Je décide d'utiliser ta fonction. En pratique tu me fournirais un fichier d'entête avec la déclaration de cette fonction. Un truc du style

Code:

---

1 2 3 4 5

#ifndef PREMS_HXX #define PREMS_HXX int * AllocateAndPopulatePrimes(const int n); #endif

---

Je l'utilise donc:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

// Mon Fichier à moi #include <prems.hxx> int main() { // Init int * lesPremiers = AllocateAndPopulatePrimes(10);   // Je m'amuse avec les premier ...   // Nettoyage: ARGH ! quelle fonction appeler ? delete lesPremiers; // Ou delete[] lesPremiers }

---

Illustration du point 2:
--
Je suis un boulet et je ne suis interessé que par un possible effet de bord de ta fonction mais pas son résultat (lire: programmeur gros crade). Je peux écrire un truc du genre:

Code:

---

1 2 3 4 5 6

#include <prems.hxx> int main() { AllocateAndPopulatePrimes(10); // YEP ! C'est de la fuite mémoire }

---

Solutions Possibles:
--
La première des solutions que je ne vois pas mentionnée ici c'est documenter son code. Notamment, la documentation doit stipuler clairement qui assume la responsabilité des objets/tableaux alloués dynamiquement. Ce type de code n'est peut-être pas esthétique, mais il s'en trimbale des centaines d'exemples parmi l'héritage de code que chaque developpeur est amené à manipuler. Donc si tu ne souhaites pas mettre en place des méchanismes spécifiques pour éviter ces problèmes d'utilisation, le minimum vital c'est de documenter.

Ensuite il existe bien sûr des solutions plus spécifiques qui on été mentionnée dans ce post.

• Utilisation d'un vecteur (resoud les points 1&2)

• Utilisation d'auto pointeurs ou pointeurs intelligents: élimine le problème de responsabilité et plus particulièrement le point 2. Cependant cela ne s'applique pas aisément aux tableaux

Voilou, en espérant que cela aide. Sinon brûlez mon post :)