2013-01-03 2 views
5

Dans l'intérêt de cette question, je représenterai la mémoire sous la forme d'un simple tableau d'octets, et je parlerai de la mémoire heap car il est possible de l'allouer dynamiquement. Supposons que j'instancie une classe et que je crée un objet sur le tas où de la mémoire a déjà été allouée. Ensuite, après avoir créé l'objet, j'alloue un peu plus de mémoire (peut-être en instanciant une autre classe). Cela implique l'utilisation des mots-clés new et delete, bien sûr.Que se passe-t-il exactement lors de la suppression de my_object; est exécuté? Toute autre mémoire est-elle décalée vers la gauche par sizeof (MyClass)?

La mémoire ressemble maintenant à ceci:

... byte byte my_object ... my_object byte byte ...

Qu'est-ce qui se passe exactement quand delete my_object; est exécuté? Toute autre mémoire est-elle décalée vers la gauche de sizeof(MyClass)? Si oui, par qui? L'OS? Alors que se passe-t-il quand il n'y a pas de système d'exploitation pour fournir de la mémoire virtuelle?

+0

Merci pour le montage Robert, c'est plus clair maintenant. – corazza

Répondre

6

Non, rien n'est décalé. Au lieu de cela, la mémoire obtient fragmented, ce qui signifie que vous avez maintenant un trou inutilisé au milieu de la mémoire utilisée. Une allocation ultérieure pourrait être en mesure de réutiliser une partie ou la totalité de cette mémoire (à condition que le nombre d'octets demandé soit suffisamment petit pour tenir dans le trou).

Certains langages/environnements prennent en charge le compactage des éboueurs. De tels collecteurs sont autorisés à déplacer des objets et peuvent donc éliminer les trous s'ils le souhaitent. De telles approches sont compliquées à mettre en œuvre puisque le collecteur a besoin de connaître l'emplacement de chaque pointeur unique dans le programme. Les collecteurs de ce type sont donc plus adaptés aux langages de niveau supérieur.

2

Si la mémoire était décalée, ce serait un mauvais OS de l'OS. Généralement, le système d'exploitation est informé que cette mémoire est disponible pour une réutilisation. Il n'est même pas nécessaire d'être effacé (et la plupart du temps ne l'est pas). Lorsque vous ne pouvez plus allouer de mémoire, vous obtenez généralement une exception (si vous utilisez new) ou un pointeur NULL (si vous utilisez malloc). Si la fragmentation est un problème (c'est parfois le cas), vous devrez écrire votre propre pool de mémoire vous pouvez utiliser des pools de mémoire (existants) qui peuvent gérer cela, mais même quand même, la plupart des responsabilités restent tombe sur le programmeur.

1

Sur une implémentation typique (sans un garbage collector mobile par exemple) rien ne sera déplacé. Selon Bames53, Herb Sutter dit que la norme dit que le mouvement automatique des objets alloués est illégal. Merci Bames53.

+0

Le compactage (ou le déplacement) des garbage collectors n'est pas autorisé en C++. – bames53

+0

Qu'est-ce qui vous donne cette idée? – Zuu

+0

La spécification C++ requiert que les valeurs de pointeur soient stables. Par exemple, si une astuce est utilisée pour masquer un pointeur afin qu'un garbage collector ne puisse pas le manipuler, lorsque la valeur du pointeur d'origine est extraite, elle doit toujours pointer vers l'objet d'origine. http://herbsutter.com/2011/10/25/garbage-collection-synopsis-and-c/ – bames53

2

La mémoire n'est pas décalée vers la gauche. Imaginez ce qui se passerait si c'était le cas. Tous ces indicateurs "sur la droite" deviendraient invalides.

+0

Le point sur les pointeurs (NPI) est grand, +1. – corazza

Questions connexes