Cela me trouble depuis un moment. Cela va au cœur de mon (manque de) compréhension de la différence entre une allocation de mémoire statique et dynamique. Le tableau suivant est un tableau statique ordinaire qui devrait signifier que la mémoire est allouée pendant la compilation, correct? Pourtant, j'ai mis en place afin que l'utilisateur entre dans la taille de la matrice au moment de l'exécution.
#include <iostream> using namespace std; int main() { cout << "how many elements should the array hold? "; int arraySize; cin >> arraySize; int arr[arraySize]; for (int i = 0; i < arraySize; ++i) arr[i] = i * 2; return 0; }
4 Réponses :
C'est un Array de longueur variable (prise en charge uniquement en C99 et non en C ++). Il est alloué sur la pile au moment de l'exécution. P>
Est-ce même valide C ++? IIRC Le studio Visual avait des erros à ce sujet.
Non, ce n'est pas une allocation de mémoire dynamique. C'est une allocation automatique de la mémoire. @stativ: Non, ce n'est pas valide C ++ (il serait valide c si non entouré de code spécifique C ++). Pour C ++, il s'agit d'une extension non standard de certains compilateurs.
@celtschk: Y a-t-il une exigence i> que la mémoire soit allouée sur la pile? Si une implémentation particulière est capable de l'attribuer sur la pile, cela serait probablement plus efficace que l'allocation de la mémoire du tas et la libérant ultérieurement, mais qu'il y aurait une raison quelconque une mise en œuvre qui ne pouvait pas utiliser la pile ne serait pas autorisée à utiliser le tas à la place?
@supercat: Il n'est pas nécessaire que ce soit sur la pile i> (ou qu'il y a une pile, pour commencer). Cependant, il y a une exigence selon laquelle il est Automatique i> Allocation de mémoire (c'est-à-dire la mémoire qui est automatiquement récupérée lors de la sortie de la fonction), pas Dynamic i> Allocation de mémoire (c'est-à-dire la mémoire Cela doit être libéré manuellement, par un appel à une fonction de la répartition de la mémoire). Je ne sais pas si appeler masloc code> /
gratuit code> par code généré par compilateur serait autorisé.
Le code généré attribuait des octets de faille sur la pile au moment de l'exécution. Une fois que la fonction renvoie, la pile se déroule, y compris "redonner" les octets qui ont été alloués à celui-ci pour la matrice. p>
Utilisation neuve et Supprimer consiste à attribuer l'espace sur le tas. La durée de vie de la mémoire allouée sur le tas est indépendante de toute fonction de fonction ou de méthode - si vous allouez de l'espace sur une fonction, et la fonction renvoie, la mémoire est toujours allouée et valide. P>
Il s'agit d'une extension non standard de vos compilateurs C ++. Notez que dans C, contrairement à C ++, cela est officiellement pris en charge (c'est-à-dire un comportement mandaté standard) depuis C99. En C ++, il n'est pas pris en charge car il existe déjà une solution au problème: utilisez Pas cependant que le tableau est pas em> à l'aide d'une allocation de mémoire statique (ni d'allocation de mémoire dynamique), mais d'une allocation de mémoire automatique. Les variables automatiques sont automatiquement traitées à la fin de la fonction (la zone de mémoire où elles sont attribuées sont connues sous le nom de pile, car les allocations et les rétroglocations de celui-ci ont une session sémantique). Pour que la matrice utilise une allocation de mémoire statique, vous devez mettre Notez que std :: vecteur code> au lieu de la matrice. P>
statique code> devant la définition (notez que les variables dans la portée de l'espace d'espace mondial ou de noms utilisent toujours une allocation de mémoire statique, cependant). Toutefois, si vous effectuez la variable statique, vous constaterez que le compilateur ne permet pas d'utiliser une taille de matrice non constante. P>
std :: vecteur code> stocke ses données avec des allocations de mémoire dynamiques à la place. Pour cette raison, vous pouvez également utiliser une taille non constante même pour static
std :: vecteur code> s. P>
La principale raison pour laquelle il n'est pas autorisé n'est pas qu'il y a une alternative du vecteur. Il y a des raisons plus profondes, comme le fait que la taille d'un tableau fait partie du type et qu'elle doit être connue au moment de la compilation.
@ Davidrodríguez-Dribesas: ils auraient pu faire des exceptions à ces règles, tout comme C de longueur variable des tableaux nécessitaient des exceptions aux règles de C.
Pour un tableau (ou un objet) déclaré à l'intérieur d'une fonction, la mémoire est allouée à l'entrée de la fonction (typiquement sur la pile) et traitée lorsque la fonction renvoie. Le fait que la fonction soit code> principale code> dans ce cas n'affecte pas cela.
ceci: p> est une "variable- Taille de longueur "(VLA). La chose est, c ++ ne prend pas en charge les VLAS. C fait, en commençant par la norme ISO C de 1999 (C99), mais ce n'est pas une fonctionnalité que c ++ a adopté. P> Votre compilateur prend en charge les VLAS en C ++ comme extension. En utilisant votre code non portable. P> (un problème avec VLAS est qu'il n'y a pas de mécanisme de détection d'une défaillance d'une répartition; si pour GCC, la compilation avec arrayate code> est trop gros, le comportement du programme est indéfini. ). P>
-pedantic code> produira un avertissement: p>
Cela utilise une fonctionnalité appelée des tableaux de longueur variable i>, qui ont fait ses débuts en C99.
Essayez de compiler avec
g ++ -wall -wextra -petic -std = c ++ 98 code>