Discussion :

[Frifron]

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.

[Jan Rendek]

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

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 ?

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 :

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

1
2
3
4
5
 
#ifndef PREMS_HXX
#define PREMS_HXX
  int * AllocateAndPopulatePrimes(const int n);
#endif

Je l'utilise donc:

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

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

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