Version imprimable
Bonjour
La fonction _alloca de la CRT permet d'allouer dynamiquement de la mémoire sur le tas.
http://msdn.microsoft.com/en-us/libr...t5(VS.80).aspx
Je voudrais savoir à quoi sert d'allouer de la mémoire dynamiquement sur la pile. (parce que sur le tas, je vois à quoi ça sert, avec l'opérateur new).
Je vous remercie
C'est beaucoup plus rapide. Il s'agit juste d'incrémenter le pointeur de la pile. Il n'y a pas à rechercher un emplacement vide.
De plus, la désallocation est tout aussi rapide.
Là, il faut des rudiments d'assembleur sur comment se déroule un appel de fonction pour comprendre comment ça marche.
Par contre attention, ce n'est absolument pas portable.
Si c'est plus rapide et qu'on peut y faire des allocation dynamique, quels sont les avantage du tas ?
J'ai toujours associé à la pile la vitesse, et au tas les allocations dynamiques, donc toujours préférer la pile sauf quand le choix ne s'offrais pas.
Pourquoi ne pas utiliser que des piles ? Plusieurs au besoin.
Pour commencer, il n'existe qu'une seule pile (d'appel) par thread -- vous savez, c'est là que l'on stocke paramètres, point de reprise du code, trucs renvoyés, et variables locales.
Et quand on sort d'une fonction, on dépile tout pour reprendre au point d'appel.
Sans parler de la taille réduite de la pile.
alloca, c'est pour faire des variables locales à taille dynamique. Les VLA reposent sur ce mécanisme -- du moins, c'est ce que je soupçonne très fortement.
C'est bien le fonctionnement que j'avais cru comprendre. Mais dans ce cas, lors d'un allocation dynamique sur la pile, tant que l'utilisateur n'a pas désalloué la variable, la pile ne peut être dépilée, et donc on ne peut pas revenir au point d'appel. J'ai du mal à comprendre comment ca marche (il faut que je cherche si je peus trouver un document expliquant le fonctionnement).
Bonjour,
C'est un euphémisme! :mrgreen:Citation:
Envoyé par Luc Hermitte
Un avantage d'alloca() est que l'allocation étant faite sur la pile, ça reste de la mémoire "automatique", donc on n'a pas besoin de faire un free().
J'ai vu ça utilisé pour des macros qui nécessitaient un buffer temporaire dont la taille n'était pas connue à la compilation.
Le personnel de Microsoft n'a apparemment pas compris ce fait quand il a développé la "CRT sécurisée", avec le spectaculaire _malloca()/_freea(), "le alloca() qui a besoin d'un free".
Il me semblait que certaines versions sont déroutées sur le tas si la pile est trop faible. D'où le besoin d'un free.