Discussion :

[Triomen]

Bonjour,

Comme dans le sujet précédent, j'ai un problème avec malloc et realloc, mais je me suis permis de créer un nouveau sujet étant donné que ce problème est un peu différent.

En effet, lorsque j'alloue avec malloc() ou realloc() de la mémoire, cela marche parfaitement, je fais d'ailleur un test juste après pour savoir si l'allocation à fonctionné ou non.

Mon projet étant un petit éditeur de texte, je redimensionne le tableau a chaque entree de caractère. Mais au bout d'un moment, aléatoirement défini, le programme plante par échec d'allocation de mémoire. Comment résoudre ce problème ? Faut-il fait un malloc que l'on pense assez grand plutôt qu'un realloc ? Mais l'intérêt de tableau dynamique est alors perdu.

Merci d'avance

[Nasky]

Salut

Montre ton code... On ne peut pas savoir d'où vient le problème sinon.
Mais normalement, il n'y a pas de raison que realloc plante "comme ça".
Allouer une taille trop grande au début fait perdre l'intérêt premier de l'allocation dynamique donc si ton programme permet de faire des realloc, continue dans cette voie.

Nas'

[Emmanuel Delahaye]

Mon projet étant un petit éditeur de texte, je redimensionne le tableau a chaque entree de caractère. Mais au bout d'un moment, aléatoirement défini, le programme plante par échec d'allocation de mémoire.

Comment ça 'plante' ? Tu veux dire plus de ressources ? malloc()/realloc() retourne NULL ? Faut être précis... Et la mémoire, tu la libères quand ?

D'autre part, faire un realloc() pour chaque caractère, c'est pas une bonne idée. Je te conseille plutôt d'allouer une taille raisonnable pour la ligne (disons, 16 caractères), puis de la doubler à la demande.

C'est sur ce principe que fonctionnent mes deux ADT FSTR (Flexible STRing) et FARR (Flexible ARRay)

http://emmanuel-delahaye.developpez.com/clib.htm

[Cunixsvp]

Salut

On ne programme jamais comme ca, dans quelque language qu'il soit ! Lorsque on rajoute juste la place pour 1 élément les temps de réponse ainsi que les fuites de mémoire se retrouve enormes! Il faut utiliser des techniques plus souples par exemple tu alloue 10% de plus que ce que tu possede ainsi tu as de la place pour 10% de saisie supplémentaire et le nombre d'appelle a malloc diminue avec le temps de saisie ( logique ).

Moi

[Triomen]

Bonjour,

Merci a tous pour les réponses rapides. Pour répondre à Emmanuel, effectivement, malloc ou realloc renvoie NULL. Et d'ailleurs, j'ai suivi son conseil pour ce qui est du ligne par ligne par exemple.
Enfin, pour répondre à Cunixsvp, effectivement, j'ai plus tard compris que c'était idiot de programme comme cela, en effet, c'est obligatoire qu'au bout d'un moment le programme plante. (revoie NULL).
Donc j'ai pensé à faire ainsi ::trouve:
- reserver à l'aide de malloc un espace taille+1 et l'affecter à un pointeur "temp"
- Copier le contenu du pointeur "texte" dans temp
- Libérer le pointeur texte
- Réaffecter texte à temp

Je pense que ça peut marcher, ça marche déjà à moitié
Merci encore de votre intérêt

[Cunixsvp]

Salut

Héhé rien de personnel mais cette approche de rajouter 1 case car il y a un élément est bizarre bien que intuitive. En effet chaque fois que tu rajoutera une element tu recopiera les n precedents et donc si tu double le nombre d'element tu as recopier pour n * n fois les n premiers éléments puis n * (n - a) le n + a eme elements. Il y a donc environs beaucoup trop de recopie en mémoire qui seront a la longue une perte de temps . Je te conseille une approche du genre : on ajoute 10% a chaque fois, on double a chaque fois la taille ou qqchose comme ca.

[gege2061]

Je te conseille une approche du genre : on ajoute 10% a chaque fois, on double a chaque fois la taille ou qqchose comme ca.

+1
Quelque chose dans ce genre là (pseusocode):

Code :

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

1
2
3
4
5
6
size_t size = 1;
if( /* Manque de place: */ )
{
  size >>= 1;  /*Multiplie pas 2 a chaque fois */
  realloc( ..., size );
}

(Merci Emmanuel)