int a [] = {1,2,}; Virgule étrange autorisée. N'importe quelle raison?

Je ne suis peut-être pas de cette planète, mais il me semble que ce qui suit devrait être une erreur de syntaxe:

int a[] = {1,2,}; //extra comma in the end

Mais ce n'est pas. J'ai été surpris lorsque ce code a été compilé sur Visual Studio, mais j'ai appris à ne pas faire confiance au compilateur MSVC en ce qui concerne les règles C ++, j'ai donc vérifié la norme et elle est également autorisée par la norme. Vous pouvez voir 8.5.1 pour les règles de grammaire si vous ne me croyez pas.

Pourquoi est-ce autorisé? C'est peut-être une stupide question inutile, mais je veux que vous compreniez pourquoi je pose la question. S'il s'agissait d'un sous-cas d'une règle de grammaire générale, je comprendrais - ils ont décidé de ne pas rendre la grammaire générale plus difficile simplement pour interdire une virgule redondante à la fin d'une liste d'initialisation. Mais non, la virgule supplémentaire est explicitement autorisée. Par exemple, il n'est pas autorisé d'avoir une virgule redondante à la fin d'une liste d'arguments d'appel de fonction (lorsque la fonction prend ...), ce qui est normal .

Donc, encore une fois, y a-t-il une raison particulière pour laquelle cette virgule redondante est explicitement autorisée?

Il facilite la génération de code source, ainsi que l'écriture de code qui peut être facilement étendu ultérieurement. Considérez ce qui est nécessaire pour ajouter une entrée supplémentaire à:

int a[] = {
   1,
   2,
   3
};

... vous devez ajouter la virgule à la ligne existante et ajouter une nouvelle ligne. Comparez cela avec le cas où les trois ont déjà une virgule après, où il vous suffit d'ajouter une ligne. De même, si vous souhaitez supprimer une ligne, vous pouvez le faire sans vous soucier de savoir s'il s'agit de la dernière ligne ou non, et vous pouvez réorganiser les lignes sans tripoter les virgules. Fondamentalement, cela signifie qu'il y a une uniformité dans la façon dont vous traitez les lignes.

Pensez maintenant à générer du code. Quelque chose comme (pseudo-code):

output("int a[] = {");
for (int i = 0; i < items.length; i++) {
    output("%s, ", items[i]);
}
output("};");

Pas besoin de vous soucier de savoir si l'élément actuel que vous écrivez est le premier ou le dernier. Beaucoup plus simple.

C'est utile si vous faites quelque chose comme ceci:

int a[] = {
  1,
  2,
  3, //You can delete this line and it's still valid
};

Facilité d'utilisation pour le développeur, je pense.

int a[] = {
            1,
            2,
            2,
            2,
            2,
            2, /*line I could comment out easily without having to remove the previous comma*/
          }

De plus, si pour une raison quelconque, vous disposiez d'un outil qui générait du code pour vous; l'outil n'a pas à se soucier de savoir s'il s'agit du dernier élément de l'initialisation ou non.

J'ai toujours supposé qu'il était plus facile d'ajouter des éléments supplémentaires:

int a[] = {
            5,
            6,
          };

devient simplement:

int a[] = { 
            5,
            6,
            7,
          };

à une date ultérieure.

Tout ce que tout le monde dit à propos de la facilité d'ajouter / supprimer / générer des lignes est correct, mais le véritable endroit où cette syntaxe brille est lors de la fusion de fichiers source. Imaginez que vous avez ce tableau:

int ints[] = {
    3,
    9
};

Et supposez que vous avez archivé ce code dans un référentiel.

Ensuite, votre copain le modifie, ajoutant à la fin:

int ints[] = {
    3,
    9,
    12
};

Et vous l'éditez simultanément, en ajoutant au début:

int ints[] = {
    1,
    3,
    9
};

Sémantiquement, ces types d'opérations (ajout au début, ajout à la fin) devraient être entièrement sécurisés par fusion et votre logiciel de versioning (avec un peu de chance git) devrait pouvoir émerger automatiquement. Malheureusement, ce n'est pas le cas car votre version n'a pas de virgule après le 9 et celle de votre copain. Alors que, si la version originale avait le 9 de fin, ils auraient fusionné automatiquement.

Donc, ma règle de base est: utilisez la virgule de fin si la liste s'étend sur plusieurs lignes, ne l'utilisez pas si la liste est sur une seule ligne.

Je pense que la virgule de fin est autorisée pour des raisons de compatibilité descendante. Il y a beaucoup de code existant, principalement généré automatiquement, qui met une virgule de fin. Cela facilite l'écriture d'une boucle sans condition particulière à la fin. par exemple

for_each(my_inits.begin(), my_inits.end(),
[](const std::string& value) { std::cout << value << ",\n"; });

Il n'y a pas vraiment d'avantage pour le programmeur.

PS Bien qu'il soit plus facile de générer automatiquement le code de cette façon, j'ai toujours pris soin de ne pas mettre la virgule de fin, les efforts sont minimes, la lisibilité est améliorée, et c'est plus important. Vous écrivez du code une fois, vous le lisez plusieurs fois.

Une des raisons pour lesquelles cela est autorisé à ma connaissance est qu'il devrait être simple de générer automatiquement du code; vous n'avez besoin d'aucune manipulation spéciale pour le dernier élément.

Il facilite les générateurs de code qui crachent des tableaux ou des énumérations.

Imaginer:

std::cout << "enum Items {\n";
for(Items::iterator i(items.begin()), j(items.end); i != j; ++i)
    std::cout << *i << ",\n";
std::cout << "};\n";

C'est-à-dire, pas besoin de faire une manipulation spéciale du premier ou du dernier élément pour éviter de cracher la virgule de fin.

Si le générateur de code est écrit en Python, par exemple, il est facile d'éviter de cracher la virgule de fin en utilisant la str.join()fonction:

print("enum Items {")
print(",\n".join(items))
print("}")

Je suis surpris après tout ce temps, personne n'a cité le manuel de référence annoté C ++ ( ARM ), il dit ce qui suit à propos de [dcl.init] avec emphase:

Il y a clairement trop de notations pour les initialisations, mais chacune semble bien servir un style particulier d'utilisation. La notation = {initializer_list, opt} a été héritée de C et sert bien à l'initialisation des structures de données et des tableaux. [...]

bien que la grammaire ait évolué depuis que ARM a été écrit, l'origine demeure.

et nous pouvons aller à la justification C99 pour voir pourquoi cela a été autorisé en C et il dit:

K&R autorise une virgule de fin dans un initialiseur à la fin d'une liste d'initialiseurs. La norme a conservé cette syntaxe, car elle offre une flexibilité dans l'ajout ou la suppression de membres d'une liste d'initialisation et simplifie la génération par ordinateur de ces listes.

Je vois un cas d'utilisation qui n'a pas été mentionné dans d'autres réponses, nos macros préférées:

int a [] = {
#ifdef A
    1, //this can be last if B and C is undefined
#endif
#ifdef B
    2,
#endif
#ifdef C
    3,
#endif
};

L'ajout de macros pour gérer en dernier ,serait très pénible. Avec ce petit changement de syntaxe, cela est trivial à gérer. Et cela est plus important que le code généré par la machine, car il est généralement beaucoup plus facile de le faire dans la langue complète de Turing que le préprocesseur très limité.

Le seul langage où il est - en pratique * - non autorisé est Javascript, et il provoque une quantité innombrable de problèmes. Par exemple, si vous copiez et collez une ligne du milieu du tableau, collez-la à la fin et oubliez de supprimer la virgule, votre site sera totalement interrompu pour vos visiteurs IE.

* En théorie, il est autorisé mais Internet Explorer ne suit pas la norme et le traite comme une erreur

C'est plus facile pour les machines, c'est-à-dire l'analyse et la génération de code. C'est aussi plus facile pour les humains, c'est-à-dire la modification, la mise en commentaire et l'élégance visuelle via la cohérence.

En supposant C, écririez-vous ce qui suit?

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
    puts("Line 1");
    puts("Line 2");
    puts("Line 3");

    return EXIT_SUCCESS
}

Non. Non seulement parce que la déclaration finale est une erreur, mais aussi parce qu'elle est incohérente. Alors pourquoi faire de même avec les collections? Même dans les langues qui vous permettent d'omettre les derniers points-virgules et virgules, la communauté n'aime généralement pas cela. La communauté Perl, par exemple, ne semble pas aimer omettre les points-virgules, sauf les lignes simples. Ils l'appliquent également aux virgules.

N'omettez pas de virgules dans les collections multilignes pour la même raison que vous ne supprimez pas les points-virgules pour les blocs de code multilignes. Je veux dire, vous ne le feriez pas même si la langue le permettait, non? Droite?

La raison est banale: facilité d'ajout / suppression de lignes.

Imaginez le code suivant:

int a[] = {
   1,
   2,
   //3, // - not needed any more
};

Maintenant, vous pouvez facilement ajouter / supprimer des éléments à la liste sans avoir à ajouter / supprimer parfois la virgule de fin.

Contrairement à d'autres réponses, je ne pense pas vraiment que la facilité de génération de la liste soit une raison valable: après tout, il est trivial que le code casse la dernière (ou la première) ligne. Les générateurs de code sont écrits une seule fois et utilisés plusieurs fois.

Il permet à chaque ligne de suivre le même formulaire. Tout d'abord, cela facilite l'ajout de nouvelles lignes et la mise en place d'un système de contrôle de version qui suit les modifications de manière significative et vous permet également d'analyser le code plus facilement. Je ne peux pas penser à une raison technique.

Cela permet de se protéger des erreurs causées par le déplacement d'éléments dans une longue liste.

Par exemple, supposons que nous ayons un code ressemblant à ceci.

#include <iostream>
#include <string>
#include <cstddef>
#define ARRAY_SIZE(array) (sizeof(array) / sizeof *(array))
int main() {
    std::string messages[] = {
        "Stack Overflow",
        "Super User",
        "Server Fault"
    };
    size_t i;
    for (i = 0; i < ARRAY_SIZE(messages); i++) {
        std::cout << messages[i] << std::endl;
    }
}

Et c'est génial, car il montre la trilogie originale des sites Stack Exchange.

Stack Overflow
Super User
Server Fault

Mais il y a un problème avec ça. Vous voyez, le pied de page de ce site Web montre une défaillance du serveur avant le super utilisateur. Mieux vaut corriger cela avant que quiconque ne le remarque.

#include <iostream>
#include <string>
#include <cstddef>
#define ARRAY_SIZE(array) (sizeof(array) / sizeof *(array))
int main() {
    std::string messages[] = {
        "Stack Overflow",
        "Server Fault"
        "Super User",
    };
    size_t i;
    for (i = 0; i < ARRAY_SIZE(messages); i++) {
        std::cout << messages[i] << std::endl;
    }
}

Après tout, déplacer des lignes ne pouvait pas être si difficile, n'est-ce pas?

Stack Overflow
Server FaultSuper User

Je sais, il n'y a pas de site Web appelé "Server FaultSuper User", mais notre compilateur prétend qu'il existe. Maintenant, le problème est que C a une fonctionnalité de concaténation de chaînes, qui vous permet d'écrire deux chaînes entre guillemets doubles et de les concaténer en utilisant rien (un problème similaire peut également se produire avec des entiers, comme- signe a plusieurs significations).

Et si le tableau d'origine avait une virgule inutile à la fin? Eh bien, les lignes seraient déplacées, mais un tel bug ne serait pas arrivé. Il est facile de rater quelque chose d'aussi petit qu'une virgule. Si vous vous souvenez de mettre une virgule après chaque élément du tableau, un tel bogue ne peut tout simplement pas se produire. Vous ne voudriez pas perdre quatre heures à déboguer quelque chose, jusqu'à ce que vous trouviez que la virgule est la cause de vos problèmes .

Comme beaucoup de choses, la virgule de fin dans un initialiseur de tableau est l'une des choses que C ++ hérite de C (et devra prendre en charge pour toujours). Une vue totalement différente de celles placées ici est mentionnée dans le livre "Deep C secrets" .

Après un exemple avec plus d'un "paradoxes de virgule":

char *available_resources[] = {
"color monitor"           ,
"big disk"                ,
"Cray"                      /* whoa! no comma! */
"on-line drawing routines",
"mouse"                   ,
"keyboard"                ,
"power cables"            , /* and what's this extra comma? */
};

nous lisons :

... que la virgule de fin après l'initialiseur final n'est pas une faute de frappe, mais une erreur dans la syntaxe transférée du C aborigène . Sa présence ou son absence est autorisée mais n'a aucune signification . La justification revendiquée dans la justification de l'ANSI C est qu'elle facilite la génération automatisée de C. L'allégation serait plus crédible si les virgules de fin étaient autorisées dans chaque liste séparée par des virgules , comme dans les déclarations d'énumération, ou dans plusieurs déclarations de variables dans une seule déclaration. Ils ne sont pas.

... pour moi, cela a plus de sens

Outre la facilité de génération et d'édition de code, si vous souhaitez implémenter un analyseur, ce type de grammaire est plus simple et plus facile à implémenter. C # suit cette règle à plusieurs endroits: il existe une liste d'éléments séparés par des virgules, comme des éléments dans une enumdéfinition.

Cela facilite la génération de code car vous n'avez besoin d'ajouter qu'une seule ligne et n'avez pas besoin de traiter l'ajout de la dernière entrée comme s'il s'agissait d'un cas spécial. Cela est particulièrement vrai lors de l'utilisation de macros pour générer du code. Il y a une pression pour essayer d'éliminer le besoin de macros de la langue, mais une grande partie de la langue a évolué main dans la main avec des macros disponibles. La virgule supplémentaire permet de définir et d'utiliser des macros telles que les suivantes:

#define LIST_BEGIN int a[] = {
#define LIST_ENTRY(x) x,
#define LIST_END };

Usage:

LIST_BEGIN
   LIST_ENTRY(1)
   LIST_ENTRY(2)
LIST_END

C'est un exemple très simplifié, mais souvent ce modèle est utilisé par des macros pour définir des éléments tels que des cartes et des tableaux de répartition, de message, d'événement ou de traduction. Si une virgule n'était pas autorisée à la fin, nous aurions besoin d'un spécial:

#define LIST_LAST_ENTRY(x) x

et ce serait très difficile à utiliser.

Ainsi, lorsque deux personnes ajoutent un nouvel élément dans une liste sur des branches distinctes, Git peut fusionner correctement les modifications, car Git fonctionne sur une base de ligne.

Si vous utilisez un tableau sans longueur spécifiée, VC ++ 6.0 peut automatiquement identifier sa longueur, donc si vous utilisez "int a [] = {1,2,};" la longueur de a est 3, mais la dernière n'a pas ' t été initialisé, vous pouvez utiliser "cout <