Je suis relativement nouveau à C ++, et depuis le début, il a été foré en moi que vous ne pouvez pas faire quelque chose comme à la place, vous devez utiliser la mémoire dynamique. Cependant, j'ai récemment découvert que ce qui précède em> compilera (bien que je reçois un avertissement à tapetique disant qu'il est interdit par ISO C ++). Je sais que c'est évidemment une mauvaise idée de le faire si cela n'est pas autorisé par la norme, mais je ne savais même pas que cela était possible. P> Ma question est, pourquoi g ++ autorise des tableaux de longueur variable qui ne sont pas dynamiquement alloués si cela n'est pas autorisé par la norme? De plus, s'il est possible que le compilateur le fasse, pourquoi n'est pas em> dans la norme? P> p>
4 Réponses :
Parce que c'est soutenu en C99. Je ne peux pas vraiment parler pourquoi ce n'est pas dans la norme C ++. Cependant, ce n'est pas aussi utile que vous pourriez penser, car il conduit facilement (si vous n'êtes pas prudent) pour empiler débordement (car il est typiquement basé sur Alloca , elle-même non standard). Une autre erreur consiste à renvoyer un pointeur à une matrice dynamique, qui sera immédiatement hors de portée. P>
Il serait donc préférable de s'en tenir à des tableaux alloués dynamiquement en C99, même si c'est dans la norme?
@Maulrus n'utilisez jamais de VLAS avec des dimensions basées sur l'entrée de l'utilisateur. Cependant, la même chose est vraie pour les matrices allouées en tas. Vous devez valider l'entrée de l'utilisateur de toute façon. Donc, je ne vois pas un problème spécifique à VLAS ici. Voici mes lignes directrices approximatives: si l'ensemble de données est petit, utilisez un petit tableau de taille statique et un INT indiquant combien d'éléments sont utilisés. Et si l'ensemble de données est grand, utilisez le tas. Je ne vois pas un cas d'utilisation pour les VLAS, cependant.
Ce n'était probablement pas dans la norme de 1995 C ++ car celle-ci précédait la normalisation C99 de réseaux de longueur variable. Ce n'est probablement pas dans la norme à venir car vecteur <> code> offre des fonctionnalités similaires.
@Maulrus: Oui, car C99 n'a pas près du soutien généralisé C89.
Prise en charge des tableaux de longueur variable (VLAS) a été ajouté au langage C en C99. P>
Il est probable que, étant donné que la prise en charge de ceux-ci existe dans GCC (pour soutenir C99), il était relativement simple d'ajouter une aide à G ++. p>
Cela dit, c'est une extension de langue spécifique à la mise en œuvre, et ce n'est pas une bonne idée d'utiliser des extensions spécifiques à la mise en œuvre si vous souhaitez que votre code soit portable. P>
Je ne savais pas que c'était dans la norme C. Cela l'explique bien, merci!
@Maulrus: N'oubliez pas que dans la norme C, cela est complètement séparé de la norme C ++.
Le lot des compilateurs embrassent et étends les normes. Il y a deux raisons de base: p>
Toutes les raisons mentionnées doivent avoir à faire avec eux étant en C sont correctes, bien qu'il existe des limitations pour l'exigence. Vous êtes exemple peut démontrer un support plus flexible que ce qui est requis dans C (si vous avez mis en place cela à l'aide de SCANF plutôt que de CIN, mettez-le dans un fichier .C et utilisé GCC). P>
Ceci est presque juste un appel implicite à Alloca (allouer automatiquement) qui diminue simplement le pointeur de pile (augmentation de la taille de la pile) et copie le nouveau pointeur de pile vers un autre registre utilisé comme un pointeur à la mémoire allouée. p>
La différence est que les constructeurs et les destructeurs ne seront pas appelés sur des objets créés avec une alloca. P>
Concernant votre dernière question, pourquoi C ++ ne les soutient pas, vous pourriez également consulter cette question: Stackoverflow.com/Questtions/1887097/variable-length-Ardrays-i nc et the comp.lang.c ++ thread relié à la réponse acceptée.