Discussion :

[loufoque]

L'allocation consiste alors à 'marquer' (derrière ce terme, tout ce que vous voulez) un bloc comme 'occupé' et la libération à le marquer comme disponible

Ça fonctionne toujours come ça, hein, même sur un bon vieux système d'exploitation de bureau... (sauf qu'il faut d'abord allouer des pages auprès de l'OS, qu'on redivise en blocs après).
Le truc c'est que tu marques pas forcément qu'un bloc, mais éventuellement plusieurs blocs contigüs. (et c'est là la difficulté de l'allocation, trouver n blocs contigüs libres, c'est pas forcément facile).

Là, il n'y a plus d'intérêt à connaitre la taille de l'allocation demandée au moment de la libération.

Tout dépend de si tu la stockes dans ton allocateur ou pas combien de blocs ont été alloués.

Mais delete[] n'a pas besoin de l'information de combien de mémoire a été allouée, mais de combien d'objets ont été construits, ça n'a rien à voir.

[white_tentacle]

Mais delete[] n'a pas besoin de l'information de combien de mémoire a été allouée, mais de combien d'objets ont été construits, ça n'a rien à voir.

D'ailleurs... Je suis surpris que new et delete utilisent malloc.

malloc a besoin de stocker quelque part la taille allouée (le plus souvent, dans les 4 octets qui précèdent le bloc il me semble) puisque free est non typé (void*).

Mais new et delete sont typés. Quand on delete un objet, on sait qu'on doit libérer la taille de cet objet. Donc, il n'y a à priori pas besoin de cette information de taille (le cas du delete[] est différent, il a besoin de l'information de nombre d'éléments, mais là encore, pas de taille).

Je loupe quelque chose, ou est-ce par "simplicité" que new utilise malloc ?

[Médinoc]

N'oublie pas qu'en POSIX, malloc() est LA primitive système pour l'allocation, donc il faut bien l'utiliser à un moment où un autre.

Par contre, sous Windows, c'est vrai que ::operator new pourrait utiliser directement HeapAlloc()...

[white_tentacle]

HeapAlloc stocke la taille du bloc mémoire alloué (sinon, je ne comprends pas comment marche HeapSize).

Mais malloc se base sur d'autres primitives système (brk, mmap... notamment). On peut le réimplémenter, et on devrait pouvoir le réimplémenter pour qu'il ne stocke pas cette taille.

[3DArchi]

Mais delete[] n'a pas besoin de l'information de combien de mémoire a été allouée, mais de combien d'objets ont été construits, ça n'a rien à voir.

Tout à fait, mais à la base la question était :

Dans ce cas, je vais laisser ma classe string comme elle est et passer à autres choses, mais par pure curiosité, quelqu'un pourrait-il m'expliquer grossièrement (si cela est possible) comment les fonctions de désallocation dynamique (comme l'opérateur delete[] par exemple) font pour libéré la bonne quantité de mémoire.

Et là, on ne discute pas du nombre d'objet pour lesquels le destructeur doit être appelé mais de quantité de mémoire.
Merci de bien lire les questions

[EDIT]: dans les systèmes embarqués où j'ai bossé, c'était plus bourrin: tu avais des pool de différentes tailles, et une allocation allait chercher un bloc dans le bon pool. Donc, impossible d'amalgamer des blocs consécutifs pour obtenir des tailles plus grandes. La taille max d'une allocation était donc bridée.

[Cbenlfun]

Merci à tous pour vos réponses.

Ma curiosité a été satisfaite.
Je comprend un peu mieux cette gestion interne et toute la complexité qu'elle implique, mais je reste bien d'accord avec Médinoc:

Mais je reconnais que cette absence de méthode standard pour connaître la taille allouée est vraiment rageante, car ça t'oblige à rajouter ta propre gestion de la taille alors que la taille est déjà gérée au niveau inférieur. Résultat, ça fait une gestion redondante et tu te retrouves avec deux (ou plus)zones mémoire contenant la taille...