Tableau de longueur variable en tête en C ++?

Question

En regardant cette question: Pourquoi un C / C ++ besoin de connaître la taille d'un tableau au moment de la compilation? il est venu pour moi que du compilateur implémenteurs auraient dû avoir un certain temps pour se mouiller les pieds maintenant (ça fait partie de la norme C99 , c'est il y a 10 ans) et fournissent des implémentations efficaces.

Cependant, il semble encore (des réponses) à considérer coûteux.

Cela me surprend en quelque sorte.

Bien sûr, je comprends qu'un décalage statique est beaucoup mieux qu'un d'une dynamique en termes de performance, et contrairement à une suggestion que je n'aurais pas fait le compilateur d'effectuer une allocation de tas du tableau car cela coûterait probablement encore plus [ cela n'a pas été mesurée;)]

Mais je suis toujours surpris du soi-disant coût :

• s'il n'y a pas VLA dans une fonction, alors il n'y aurait pas de coût, pour autant que je peux voir.
• s'il y a un seul VLA, alors on peut soit le mettre avant ou après toutes les variables, et donc obtenir un décalage statique pour la plupart du cadre de la pile (ou alors il me semble, mais je ne suis pas bien versé dans la gestion de la pile)

La question se pose de multiples VLA bien sûr, et je me demandais si avoir une pile de VLA dédié fonctionnerait. Ce moyen qu'un VLA seraient représentés par un nombre et un pointeur (de tailles donc connues) et la mémoire réelle prise dans une pile secondaire utilisé uniquement à cette fin (et donc vraiment une pile trop).

[reformulant]

Comment VLA sont mises en œuvre dans gcc / VC ++?

Le coût vraiment impressionnant?

[reformulation d'extrémité]

Il me semble que ce ne peut être mieux que d'utiliser, par exemple, un vector, même avec les implémentations actuelles, puisque vous ne subissez pas le coût d'une allocation dynamique (au prix de ne pas être redimensionnable).

EDIT:

Il y a une réponse partielle , cependant on compare VLA aux réseaux traditionnels semblent injustes . Si nous savions la taille à l'avance, nous aurions pas besoin d'un VLA. Dans la même question AndreyT a donné quelques conseils en ce qui concerne la mise en œuvre, mais il est pas aussi précis que je le voudrais.

Answer 1

  

Comment VLA sont mises en œuvre dans gcc / VC ++?

VC ++ ne AFAIK implémente pas VLA. Il est un compilateur C ++ et il ne supporte que C89 (pas VLA, restreindre non). Je ne sais pas comment gcc implémente VLA mais le meilleur moyen possible est de stocker le pointeur sur le VLA et sa taille dans la partie statique de la pile cadre. De cette façon, vous pouvez accéder à l'un des VLA avec des performances d'un tableau de taille constante (il est le dernier VLA si la pile pousse vers le bas comme dans x86 (déréférencement [pointeur de pile + index * taille de l'élément + la taille des dernières poussées temporaires]), et le premier VLA si elle se développe vers le haut (déréférencer [pointeur StackFrame + décalé par rapport à StackFrame + index * la taille de l'élément])). Tous les autres VLA auront besoin d'un plus indirection pour obtenir leur adresse de base de la partie statique de la pile.

[ Edit: également lors de l'utilisation VLA le compilateur ne peut pas omettre pointeur pile cadre de base, ce qui est redondant par ailleurs, parce que tous les décalages du pointeur de la pile peut être calculé au cours de la compilation. Vous avez donc un registre moins libre. - modifier fin ]

  

Le coût vraiment impressionnant?

Pas vraiment. De plus, si vous ne l'utilisez pas, vous ne payez pas.

[ Edit: Probablement une réponse plus correcte serait: Par rapport à quoi? Par rapport à un vecteur alloué tas, le temps d'accès sera le même, mais l'allocation et désallocation sera plus rapide. - modifier fin ]

Answer 2

Si elle devait être mise en œuvre en VC ++, je suppose que l'équipe du compilateur utiliserait une variante de _alloca(size). Je crois que le coût est équivalent à l'aide de variables avec un alignement supérieur à 8 octets sur la pile (comme __m128); le compilateur doit stocker quelque part le pointeur de la pile d'origine, et l'alignement de la pile nécessite un registre supplémentaire pour stocker la pile non alignée.

Donc les frais généraux est essentiellement une indirection supplémentaire (vous devez stocker l'adresse de quelque part VLA) et enregistrer la pression en raison de stockage de la part de la plage de la pile d'origine aussi bien.