Discussion :

[theludovyc]

Bonjour,

Cette discussion viens en suite de celle-ci https://www.developpez.net/forums/d1...ire-d-origine/

Résumé :

Un code possible de realloc par @dalfab:

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
void *realloc( void *blocACopier , size_t nouvelleTaille ) {
   size_t  alloues = 0;     // bytes réservés
   size_t  taille = 0;      // bytes utilisables
   if ( blocACopier ) {
      alloues = ((size_t*)blocACopier)[-1]; // une structure possible ou une autre?
      taille  = ((size_t*)blocACopier)[-2];
      while ( nouvelleTaille > alloues  &&  la-zone-suivant-le-bloc-est-disponible ) {
         fusionner-le-bloc-avec-le-bloc-suivant-et-trouver-nouvelle-valeur-pour-'alloues'
         ((size_t*)blocACopier)[-1] = alloues;
      }
   }
   if ( nouvelleTaille > alloues ) {        // allocation nécessaire ailleurs
      void *tmp = malloc( nouvelleTaille ); //allocation d'une nouvelle zone mémoire et 2*size_t avant
      if ( !tmp ) return NULL;
      if ( blocAcopier ) {
         memcpy( tmp , blocACopier , taille );
         free( blocACopier );
         blocACopier = tmp;
      }
   }
   else { // assez ou trop grand
      if ( nouvelleTaille + TAILLE_HYSTERESIS < alloues ) { // trop grand
         couper-le-bloc-ne-garder-que-le-necessaire-et-trouver-nouvelle-valeur-pour-'alloues'
         ((size_t*)blocACopier)[-1] = alloues;
      }
      ((size_t*)blocACopier)[-2] = nouvelleTaille;  // noter la nouvelle taille utile
   }
   return blocACopier;
}

Pourquoi allez chercher les tailles d'allocation n'est pas standardisé?

Pour interdire aux programmeurs d'aller consulter ces données et faire des bidouilles avec ?

Si vous le faites, c'est à vos risques et périls.

Le fait est que le standard C ne prévoit aucun moyen de demander à l'implémentation la taille d'un bloc alloué. Choix délibéré ou oubli, je l'ignore.
D'autres bibliothèques faisant de l'allocation de mémoire (comme les diverses de Windows) proposent de telles fonctions (LocalSize()/GlobalSize() pour LocalAlloc()/GlobalAlloc() (retournent la taille réelle du bloc, qui peut être plus grande que celle initialement demandée), HeapSize() pour HeapAlloc(), VirtualQuery() pour VirtualAlloc(), mais rien pour la mémoire allouée via CoTaskMemAlloc())

Résultat, si tu fais un programme en C standard, c'est à toi de garder trace des tailles allouées (y compris, par exemple, en utilisant la tactique mentionnée par dalfab).

Quelle en serait l'utilité ? Ce serait imposer d'énormes contraintes au système d'allocation pour bien peu d'avantages offerts au programmeur au final.

malloc fonctionne sur des systèmes différents allant de Linux à MS-DOS. Il peut donc être logique que la façon dont la fonction gère l'allocation soit différente et qu'il ne faille pas "bricoler". C'est l'intérêt d'une fonction système, tu ne te préoccupe pas de son fonctionnement, tu lui donnes une (ou plusieurs) entrée(s) et tu attend un résultat en sortie.

Tu peux toujours étudier le code source de la fonction.

Ou plus facile d'accès un tuto comme celui-ci :
http://www.inf.udec.cl/~leo/Malloc_tutorial.pdf

Fin du résumé.

Je comprend que ce soit le système qui gère l'allocation, que les fonctions soit simplement un dialogue avec lui. Et son intérêt! Comme cela c'est adaptable sur tout support. Ce qui m'embête c'est que l'on est pas accès à tout. Obligé le programmeur à enregistrer lui même les tailles quand il en a besoin alors que le système le sais très bien c'est pas terrible... J'ai aussi découvert que la fonction recalloc n'existe pas. Bref c'est un manque que je trouve dommage.

Je ne vois pas en quoi cela pourrait ajouter d'énormes contraintes au système d'allocation, vu qu'il a déjà l'air de le faire? Où que ce serait meilleur d'interdire les programmeurs de jouer avec...

C'est pour cela que j'aimerai vous poser la question suivante : Est ce qu'une amélioration de la bibliothèque standard sur l'allocation dynamique serait une bonne chose? Offrir une plus grande liberté au programmeur et une meilleur interaction avec le système.