Je me demande si la norme C ou C ++ garantit qu'un pointeur n'est pas modifié lorsque Realloc s'appelle avec une taille réel (non nulle): essentiellement, le système d'exploitation peut-il décider de son Posséder que depuis que nous avons libéré un grand bloc de mémoire, il souhaite profiter de tous les réallocs pour défragmenter la mémoire et déplacer en quelque sorte PTR2?
6 Réponses :
avec realloc , vous n'êtes absolument pas de garanties sur l'endroit où la mémoire vivra des mots de mémoire. Je crois que le MALLOC par défaut de Libc ne copiera que de la mémoire de la mémoire, donc de manière pratique que vous puissiez être ok. Mais ne comptez pas dessus.
Plus tôt sur cette page, il est indiqué que "la fonction REALLOC () modifie la taille de l'objet de mémoire pointé par PTR à la taille spécifiée par taille. Le contenu de l'objet restera inchangé jusqu'au moindre des tailles nouvelles et anciennes. Si la nouvelle taille de l'objet de mémoire nécessiterait un mouvement de l'objet, l'espace de l'instanciation précédente de l'objet est libéré. " Cela n'exclut pas le mouvement, mais il est relativement improbable.
Oui, vous êtes toujours assuré que tout ce qui était en mémoire avant de rester là, merci de pointer cela
sur Windows, le C-Runtime saisit un tas, puis attribue la mémoire de ce tas. Donc, le système d'exploitation ne saura pas sur les allocations de mémoire individuelles et ne déplacera donc pas les choses autour.
Ce n'est pas correct. Le temps d'exécution Visual C n'appelle pas directement la mise en œuvre du tas de système d'exploitation, pour une chose. Pour un autre, l'appel de HeemPealloc () fait déplacer des choses autour.
Vous devez vérifier vos documents. Voir: msdn.microsoft.com/en-us/library/csd157zx.aspx < / a> Le CRT saisit un seul tas de système d'exploitation à utiliser en interne. Il sous-alloue ensuite ce tas (ce qui signifie qu'il n'utilise pas les appels de tas Win32 pour faire des allocations dans ce tas)
Il n'y a pas de garantie realloc retournera le même emplacement, la même période.
Ce serait bien si cela était définitivement énoncé quelque part. Ne disant pas que "X est garanti pour arriver" n'est pas la même chose que spécifiquement indiquant que "x n'est pas garantie".
@Rog oui, c'est en fait. Ne pas spécifier des garanties signifie aucune garantie.
@klutt Je vois ton point, mais il serait toujours agréable de le voir définitivement altéré quelque part, par ex. Dans un livre, sinon dans la documentation. Du point de vue de l'utilisateur, ne pas pouvoir trouver une garantie signifie qu'il n'y en a pas, ni ils ont regardé au mauvais endroit.
@ROG si cela n'est pas indiqué dans la norme, vous pouvez alors écrire une implémentation conforme sans cette garantie. Donc, si la norme ne l'exige pas, vous ne pouvez pas vous en attendre d'implémentations en général. Bien sûr, vous pouvez toujours écrire une implémentation qui a cette garantie, car elle ne violerait pas la norme. Alors regardez dans la norme ou dans la documentation pour une implémentation spécifique. Mais c'est aussi simple que possible que la norme ne l'exige pas, la garantie n'existe pas dans le cas général.
@ROG Aussi, voulant que de telles preuves soit un peu comme Théière de Russell .
Cela peut sembler ridicule, mais parfois pour des systèmes embarqués, une implémentation comme je viens de décrire est en réalité optimale. realloc n'est pas obligé de laisser le bloc en place même s'il convient, et en fait, l'implémentation de stud la plus simple est un exemple où elle pourrait ne pas:
malloc : appel sbrk .
realloc : appel malloc et memcpy .
gratuit : no-op.
Un autre exemple est une implémentation dans laquelle toutes les allocations adjacentes sont des blocages de la même taille afin d'éviter la fragmentation. Dans ce cas, un bloc de 32 octets n'appartient plus au même endroit que l'ancien bloc de 4096 octets.
Oui. Un autre exemple plus avancé serait une implémentation qui examine si le voisin de gauche du bloc à rétréser est libre, qu'il s'agisse d'un bloc libre significatif soient créés à droite en rétrécissant, que la taille résultante soit "assez petite "Que memcpy n'est pas trop cher ... et si les bonnes conditions sont remplies, déplace le bloc vers un nouvel emplacement pour éviter la fragmentation.
Il me semble que toutes les réponses actuelles (au moment de cette réponse) ne font référence à aucun document standard.
pour C ++ je ferai référence à < EM> Projet de travail, Standard pour la programmation Language C ++ , Numéro de document: N3337, Date: 2012-01-16, révise: N3291 qui, selon https://isocpp.org/std/the-tandard est le document gratuit le plus proche du document standard officiel non libre C ++ 11 ; Nous trouvons ici la bibliothèque 20.6.13 C :
2 Le contenu est identique à l'en-tête Standard C Bibliothèque,
avec les modifications suivantes: [À mon avis, les modifications énumérées ne sont pas pertinentes pour la
Question].
Alors maintenant, nous devons nous référer à la norme C.
Selon https://stackoverflow.com/a/83763/15485 le document libre le plus proche de la non- Le document Standard C11 officiel gratuit est Langues de programmation - C , projet de comité N1570 - 12 avril 2011 ISO / CEI 9899: 201X ; Nous trouvons ici 7.22.3.5 la fonction Realloc :
4 La fonction Realloc renvoie un pointeur sur le nouvel objet ( Je ne suis pas un orienté anglais indigène et vous devez donc interpréter le sens de "peut avoir".
Je suis un locuteur anglais natif (et bien familier avec la norme C). Le texte cité indique que le nouveau pointeur peut avoir la même valeur que l'ancien pointeur, sans aucune implication que cela dépend de la taille. Une justification (non indiquée dans la norme) est qu'une implémentation pourrait affecter un plus petit morceau dans un endroit différent pour réduire la fragmentation et rendre les allocations futures plus susceptibles de réussir. Pour qu'il y ait une garantie qu'il n'est pas déplacé dans certains cas, cela devrait être indiqué explicitement dans la norme. Ce n'est pas le cas.