Pourquoi les tableaux de longueur variable ne font-ils pas partie de la norme C ++?

Je n'ai pas beaucoup utilisé C au cours des dernières années. Quand j'ai lu cette question aujourd'hui, je suis tombé sur une syntaxe C que je ne connaissais pas.

Apparemment, en C99, la syntaxe suivante est valide:

void foo(int n) {
    int values[n]; //Declare a variable length array
}

Cela semble être une fonctionnalité assez utile. Y a-t-il déjà eu une discussion sur l'ajout à la norme C ++, et si oui, pourquoi a-t-il été omis?

Quelques raisons potentielles:

• Poilu pour les éditeurs de compilateurs à implémenter
• Incompatible avec une autre partie de la norme
• La fonctionnalité peut être émulée avec d'autres constructions C ++

La norme C ++ stipule que la taille du tableau doit être une expression constante (8.3.4.1).

Oui, bien sûr, je me rends compte que dans l'exemple de jouet on pourrait utiliser std::vector<int> values(m);, mais cela alloue de la mémoire à partir du tas et non de la pile. Et si je veux un tableau multidimensionnel comme:

void foo(int x, int y, int z) {
    int values[x][y][z]; // Declare a variable length array
}

la vectorversion devient assez maladroite:

void foo(int x, int y, int z) {
    vector< vector< vector<int> > > values( /* Really painful expression here. */);
}

Les tranches, les lignes et les colonnes seront également potentiellement réparties sur toute la mémoire.

En regardant la discussion, comp.std.c++il est clair que cette question est assez controversée avec des noms très lourds des deux côtés de l'argument. Il n'est certainement pas évident que a std::vectorsoit toujours une meilleure solution.

Il y a eu récemment une discussion à ce sujet dans usenet: Pourquoi aucun VLA en C ++ 0x .

Je suis d'accord avec ces gens qui semblent être d'accord pour dire que devoir créer un grand tableau potentiel sur la pile, qui n'a généralement que peu d'espace disponible, n'est pas bon. L'argument est que si vous connaissez la taille au préalable, vous pouvez utiliser un tableau statique. Et si vous ne connaissez pas la taille à l'avance, vous écrirez du code dangereux.

Les VLA C99 pourraient offrir un petit avantage de pouvoir créer de petits tableaux sans gaspiller d'espace ni appeler des constructeurs pour les éléments inutilisés, mais ils introduiront des changements assez importants dans le système de types (vous devez être en mesure de spécifier des types en fonction des valeurs d'exécution - cela n'existe pas encore dans le C ++ actuel, à l'exception des newspécificateurs de type d'opérateur, mais ils sont traités spécialement, de sorte que le runtime-ness n'échappe pas à la portée de l' newopérateur).

Vous pouvez utiliser std::vector, mais ce n'est pas tout à fait la même chose, car il utilise la mémoire dynamique, et le faire utiliser son propre allocateur de pile n'est pas exactement facile (l'alignement est également un problème). Cela ne résout pas non plus le même problème, car un vecteur est un conteneur redimensionnable, alors que les VLA sont de taille fixe. La proposition de matrice dynamique C ++ vise à introduire une solution basée sur une bibliothèque, comme alternative à un VLA basé sur un langage. Cependant, cela ne fera pas partie de C ++ 0x, pour autant que je sache.

(Contexte: J'ai une certaine expérience de la mise en œuvre des compilateurs C et C ++.)

Les tableaux de longueur variable en C99 étaient fondamentalement un faux pas. Afin de soutenir les VLA, C99 a dû faire les concessions suivantes au bon sens:

• sizeof xn'est plus toujours une constante de compilation; le compilateur doit parfois générer du code pour évaluer une sizeofexpression au moment de l'exécution.

• Permettre à deux dimensions VLA ( int A[x][y]) nécessaire une nouvelle syntaxe pour déclarer des fonctions qui prennent 2D VLA comme paramètres: void foo(int n, int A[][*]).

• Moins important dans le monde C ++, mais extrêmement important pour le public cible de C des programmeurs de systèmes embarqués, déclarer un VLA signifie chomping un arbitrairement grand morceau de votre pile. Il s'agit d'un débordement de pile et d'un plantage garantis . (Chaque fois que vous déclarez int A[n], vous affirmez implicitement que vous avez 2 Go de pile à épargner. Après tout, si vous savez " nest certainement inférieur à 1000 ici", alors vous déclareriez simplement int A[1000]. La substitution de l'entier 32 bits npour 1000est une admission que vous n'avez aucune idée du comportement de votre programme.)

Bon, passons maintenant à parler de C ++ maintenant. En C ++, nous avons la même distinction forte entre "système de types" et "système de valeurs" que C89… mais nous avons vraiment commencé à nous y fier d'une manière que C n'a pas. Par exemple:

template<typename T> struct S { ... };
int A[n];
S<decltype(A)> s;  // equivalently, S<int[n]> s;

Si n n'était pas une constante de temps de compilation (c.-à-d., Si elle Aétait de type modifié de façon variable), alors quel serait le type de ce type S? Would Stype de » également être déterminée que lors de l' exécution?

Et ça:

template<typename T> bool myfunc(T& t1, T& t2) { ... };
int A1[n1], A2[n2];
myfunc(A1, A2);

Le compilateur doit générer du code pour une certaine instanciation de myfunc. À quoi devrait ressembler ce code? Comment pouvons-nous générer statiquement ce code, si nous ne connaissons pas le type A1au moment de la compilation?

Pire encore, que se passe-t-il s'il s'avère au moment de l'exécution que n1 != n2 , alors !std::is_same<decltype(A1), decltype(A2)>()? Dans ce cas, l'appel à myfunc ne devrait même pas être compilé , car la déduction du type de modèle devrait échouer! Comment pourrions-nous éventuellement émuler ce comportement lors de l'exécution?

Fondamentalement, C ++ évolue dans le sens de pousser de plus en plus de décisions au moment de la compilation : génération de code de modèle, constexprévaluation de fonction, etc. Pendant ce temps, C99 était occupé à pousser les décisions traditionnelles de compilation (par exemple sizeof) dans le runtime . Dans cet esprit, est-il vraiment logique de consacrer des efforts à essayer d'intégrer des VLA de style C99 dans C ++?

Comme tous les autres répondeurs l'ont déjà souligné, C ++ fournit de nombreux mécanismes d'allocation de tas ( std::unique_ptr<int[]> A = new int[n];ou std::vector<int> A(n);étant les plus évidents) lorsque vous voulez vraiment transmettre l'idée "Je n'ai aucune idée de la quantité de RAM dont j'ai besoin". Et C ++ fournit un modèle astucieux de gestion des exceptions pour faire face à la situation inévitable où la quantité de RAM dont vous avez besoin est supérieure à la quantité de RAM dont vous disposez. Mais j'espère que cela réponse vous donne une bonne idée de pourquoi les VLA de style C99 n'étaient pas un bon ajustement pour C ++ - et pas vraiment même un bon ajustement pour C99. ;)

Pour plus d'informations sur le sujet, consultez N3810 «Alternatives pour les extensions de baie» , article d'octobre 2013 de Bjarne Stroustrup sur les VLA. Le POV de Bjarne est très différent du mien; N3810 se concentre davantage sur la recherche d'une bonne syntaxe ish C ++ pour les choses, et sur le découragement de l'utilisation de tableaux bruts en C ++, tandis que je me concentrais davantage sur les implications pour la métaprogrammation et le système de types. Je ne sais pas s'il considère que les implications de la métaprogrammation / système de types sont résolues, résolubles ou simplement sans intérêt.

Un bon article de blog qui touche bon nombre de ces mêmes points est "Utilisation légitime des tableaux à longueur variable" (Chris Wellons, 27/10/2019).

Vous pouvez toujours utiliser alloca () pour allouer de la mémoire sur la pile au moment de l'exécution, si vous le souhaitez:

void foo (int n)
{
    int *values = (int *)alloca(sizeof(int) * n);
}

L'allocation sur la pile implique qu'elle sera automatiquement libérée lors du déroulement de la pile.

Remarque rapide: comme mentionné dans la page de manuel Mac OS X pour alloca (3), "La fonction alloca () dépend de la machine et du compilateur; son utilisation est déconseillée." Juste pour que tu saches.

Dans mon propre travail, j'ai réalisé que chaque fois que je voulais quelque chose comme des tableaux automatiques de longueur variable ou alloca (), je me fichais vraiment que la mémoire soit physiquement située sur la pile cpu, juste qu'elle provenait de un allocateur de pile qui n'a pas subi de déplacements lents vers le tas général. J'ai donc un objet par thread qui possède de la mémoire à partir de laquelle il peut pousser / pop des tampons de taille variable. Sur certaines plates-formes, je laisse cela se développer via mmu. D'autres plates-formes ont une taille fixe (généralement accompagnée d'une pile de processeurs de taille fixe également car aucun mmu). Une plate-forme avec laquelle je travaille (une console de jeu portable) possède de toute façon une petite pile de processeurs précieuse car elle réside dans une mémoire rapide et rare.

Je ne dis pas que pousser des tampons de taille variable sur la pile cpu n'est jamais nécessaire. Honnêtement, j'ai été surpris lorsque j'ai découvert que ce n'était pas standard, car il semble certainement que le concept s'intègre assez bien dans le langage. Pour moi cependant, les exigences "taille variable" et "doivent être physiquement situées sur la pile cpu" ne se sont jamais réunies. Il s'agissait de vitesse, donc j'ai créé ma propre sorte de "pile parallèle pour les tampons de données".

Il existe des situations où l'allocation de mémoire de tas est très coûteuse par rapport aux opérations effectuées. Un exemple est les mathématiques matricielles. Si vous travaillez avec de petites matrices, dites 5 à 10 éléments et faites beaucoup d'arithmétiques, les frais généraux du malloc seront vraiment importants. En même temps, faire de la taille une constante de temps de compilation semble très gaspilleur et rigide.

Je pense que C ++ est si dangereux en soi que l'argument pour "essayer de ne pas ajouter plus de fonctionnalités dangereuses" n'est pas très fort. En revanche, comme C ++ est sans doute le langage de programmation le plus efficace, ce qui le rend encore plus utile est toujours utile: les personnes qui écrivent des programmes critiques en termes de performances utiliseront dans une large mesure C ++, et elles auront besoin d'autant de performances que possible. Le déplacement de trucs du tas vers la pile est une de ces possibilités. La réduction du nombre de blocs de tas en est une autre. Autoriser les VLA en tant que membres d'objets serait un moyen d'y parvenir. Je travaille sur une telle suggestion. C'est un peu compliqué à mettre en œuvre, certes, mais cela semble tout à fait faisable.

Semble qu'il sera disponible en C ++ 14:

https://en.wikipedia.org/wiki/C%2B%2B14#Runtime-sized_one_dimensional_arrays

Mise à jour: il n'est pas entré en C ++ 14.

Cela a été envisagé pour inclusion dans C ++ / 1x, mais a été abandonné (c'est une correction à ce que j'ai dit plus tôt).

Ce serait de toute façon moins utile en C ++ puisque nous devons déjà std::vectorremplir ce rôle.

Utilisez std :: vector pour cela. Par exemple:

std::vector<int> values;
values.resize(n);

La mémoire sera allouée sur le tas, mais cela ne présente qu'un petit inconvénient de performances. De plus, il est sage de ne pas allouer de gros blocs de données sur la pile, car sa taille est plutôt limitée.

C99 autorise VLA. Et cela impose des restrictions sur la façon de déclarer VLA. Pour plus de détails, reportez-vous au 6.7.5.2 de la norme. C ++ interdit VLA. Mais g ++ le permet.

Des tableaux comme celui-ci font partie de C99, mais ne font pas partie de C ++ standard. comme d'autres l'ont dit, un vecteur est toujours une bien meilleure solution, c'est probablement pourquoi les tableaux de taille variable ne sont pas dans la norme C ++ (ou dans la norme C ++ 0x proposée).

BTW, pour des questions sur "pourquoi" la norme C ++ est la façon dont elle est, le groupe de discussion Usenet modéré comp.std.c ++ est l'endroit où aller.

Si vous connaissez la valeur au moment de la compilation, vous pouvez effectuer les opérations suivantes:

template <int X>
void foo(void)
{
   int values[X];

}

Modifier: vous pouvez créer un vecteur qui utilise un allocateur de pile (alloca), car l'allocateur est un paramètre de modèle.

J'ai une solution qui a vraiment fonctionné pour moi. Je ne voulais pas allouer de mémoire en raison de la fragmentation d'une routine qui devait s'exécuter plusieurs fois. La réponse est extrêmement dangereuse, alors utilisez-la à vos risques et périls, mais elle profite de l'assemblage pour réserver de l'espace sur la pile. Mon exemple ci-dessous utilise un tableau de caractères (évidemment, une autre variable de taille nécessiterait plus de mémoire).

void varTest(int iSz)
{
    char *varArray;
    __asm {
        sub esp, iSz       // Create space on the stack for the variable array here
        mov varArray, esp  // save the end of it to our pointer
    }

    // Use the array called varArray here...  

    __asm {
        add esp, iSz       // Variable array is no longer accessible after this point
    } 
}

Les dangers ici sont nombreux mais j'expliquerai quelques-uns: 1. Changer la taille de la variable à mi-chemin tuerait la position de la pile 2. Le dépassement des limites du tableau détruirait les autres variables et le code possible 3. Cela ne fonctionne pas en 64 bits build ... nécessite un assemblage différent pour celui-ci (mais une macro pourrait résoudre ce problème). 4. Spécifique au compilateur (peut avoir du mal à se déplacer entre les compilateurs). Je n'ai pas essayé donc je ne sais vraiment pas.