Discussion :

[mailaka]

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

Example 65 Dangerous memory management

Code :

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

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 ?

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

[loufoque]

Code :

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

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.

[@Ikey]

Pour répondre à ta question il faut rappeller les bases de l'utilisation d'un pointeur:

Code :

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

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 :

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

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.

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

@Ikey

[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 :

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

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 ?

[mailaka]

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 ?

[Médinoc]

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

Code :

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

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.

[@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 :

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

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:

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

[Médinoc]

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

[@Ikey]

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

Autant pour moi, je me suis très mal exprimé. 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

[Médinoc]

Et en plus il est sérieux...

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.

[Sylvain Togni]

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

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

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.

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

[loufoque]

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

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

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

[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

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 ?

[Médinoc]

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

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.

[mailaka]

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

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.

RVO et NRVO : (Named) Return Value Optimization.

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

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

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

Code :

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

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 :

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

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.