Discussion :

[deubelte]

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

[Luc Hermitte]

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.

[Flob90]

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.

[Luc Hermitte]

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.

[Flob90]

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).

[Aleph69]

Bonjour,

Sans parler de la taille réduite de la pile.

C'est un euphémisme!

[Médinoc]

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".

[Luc Hermitte]

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.