int a [] = {1,2,}; Se permite una coma extraña. ¿Alguna razón en particular?

Tal vez no soy de este planeta, pero me parece que lo siguiente debería ser un error de sintaxis:

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

Pero no lo es. Me sorprendió cuando este código se compiló en Visual Studio, pero aprendí a no confiar en el compilador MSVC en lo que respecta a las reglas de C ++, por lo que verifiqué el estándar y también está permitido por el estándar. Puedes ver 8.5.1 para las reglas gramaticales si no me crees.

¿Por qué está permitido esto? Esta puede ser una pregunta estúpida e inútil, pero quiero que entiendas por qué te pregunto. Si se tratara de un caso secundario de una regla gramatical general, lo entendería: decidieron no hacer que la gramática general sea más difícil simplemente para no permitir una coma redundante al final de una lista de inicializadores. Pero no, la coma adicional está explícitamente permitida. Por ejemplo, no está permitido tener una coma redundante al final de una lista de argumentos de llamada a función (cuando la función toma ...), lo cual es normal .

Entonces, de nuevo, ¿hay alguna razón particular por la cual esta coma redundante esté explícitamente permitida?

Facilita la generación de código fuente y también la escritura de código que puede ampliarse fácilmente en una fecha posterior. Considere qué se requiere para agregar una entrada adicional a:

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

... debe agregar la coma a la línea existente y agregar una nueva línea. Compare eso con el caso donde los tres ya tienen una coma después, donde solo tiene que agregar una línea. Del mismo modo, si desea eliminar una línea, puede hacerlo sin preocuparse de si es la última línea o no, y puede reordenar las líneas sin jugar con comas. Básicamente significa que hay una uniformidad en la forma en que tratas las líneas.

Ahora piense en generar código. Algo como (pseudocódigo):

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

No debe preocuparse si el elemento actual que está escribiendo es el primero o el último. Mucho mas simple.

Es útil si haces algo como esto:

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

Facilidad de uso para el desarrollador, creo.

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

Además, si por alguna razón tuvo una herramienta que generó código para usted; la herramienta no tiene que preocuparse por si es el último elemento en la inicialización o no.

Siempre he asumido que hace que sea más fácil agregar elementos adicionales:

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

simplemente se convierte en:

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

en una fecha posterior.

Todo lo que todos dicen sobre la facilidad de agregar / eliminar / generar líneas es correcto, pero el verdadero lugar en el que brilla esta sintaxis es cuando se combinan los archivos de origen. Imagina que tienes esta matriz:

int ints[] = {
    3,
    9
};

Y suponga que ha verificado este código en un repositorio.

Luego, tu amigo lo edita y agrega al final:

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

Y simultáneamente lo editas, agregando al principio:

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

Semánticamente, este tipo de operaciones (agregar al principio, agregar al final) debe ser completamente seguro y su software de versiones (con suerte git) debería ser capaz de automatizar. Lamentablemente, este no es el caso porque su versión no tiene coma después del 9 y la de su amigo sí. Mientras que, si la versión original tuviera el 9 final, se habrían automatizado.

Entonces, mi regla general es: use la coma final si la lista abarca varias líneas, no la use si la lista está en una sola línea.

La coma final, creo, está permitida por razones de compatibilidad con versiones anteriores. Hay una gran cantidad de código existente, principalmente generado automáticamente, que pone una coma final. Hace que sea más fácil escribir un bucle sin condiciones especiales al final. p.ej

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

Realmente no hay ninguna ventaja para el programador.

PD: Aunque es más fácil generar automáticamente el código de esta manera, en realidad siempre me ocupé de no poner la coma final, los esfuerzos son mínimos, se mejora la legibilidad y eso es más importante. Escribe el código una vez, lo lee muchas veces.

Una de las razones por las que esto está permitido hasta donde yo sé es que debería ser simple generar código automáticamente; no necesita ningún manejo especial para el último elemento.

Hace que los generadores de código que escupen matrices o enumeraciones sean más fáciles.

Imagina:

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

Es decir, no es necesario hacer un manejo especial del primer o último elemento para evitar escupir la coma final.

Si el generador de código está escrito en Python, por ejemplo, es fácil evitar escupir la coma final utilizando la str.join()función:

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

Me sorprende que, después de todo este tiempo, nadie haya citado el Manual de referencia anotado de C ++ ( ARM ), que dice lo siguiente sobre [dcl.init] con énfasis en el mío:

Claramente, hay demasiadas anotaciones para las inicializaciones, pero cada una parece servir bien a un estilo particular de uso. La notación = {initializer_list, opt} fue heredada de C y sirve bien para la inicialización de estructuras de datos y matrices. [...]

aunque la gramática ha evolucionado desde que se escribió ARM, el origen permanece.

y podemos ir a la justificación de C99 para ver por qué esto se permitió en C y dice:

K&R permite una coma final en un inicializador al final de una lista de inicializadores. El Estándar ha conservado esta sintaxis, ya que proporciona flexibilidad para agregar o eliminar miembros de una lista de inicializadores, y simplifica la generación automática de tales listas.

Veo un caso de uso que no se mencionó en otras respuestas, nuestras Macros favoritas:

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

Agregar macros para manejar el último ,sería un gran dolor. Con este pequeño cambio en la sintaxis, esto es trivial de administrar. Y esto es más importante que el código generado por la máquina porque generalmente es mucho más fácil hacerlo en una lengua completa de Turing que un preprocesador muy limitado.

El único lenguaje donde, en la práctica *, no está permitido es Javascript, y causa una cantidad innumerable de problemas. Por ejemplo, si copia y pega una línea desde el centro de la matriz, péguela al final y olvidó eliminar la coma, entonces su sitio estará totalmente roto para sus visitantes de IE.

* En teoría está permitido, pero Internet Explorer no sigue el estándar y lo trata como un error

Es más fácil para las máquinas, es decir, el análisis y la generación de código. También es más fácil para los humanos, es decir, modificación, comentarios y elegancia visual a través de la coherencia.

Suponiendo C, ¿escribirías lo siguiente?

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

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

    return EXIT_SUCCESS
}

No. No solo porque la declaración final es un error, sino también porque es inconsistente. Entonces, ¿por qué hacer lo mismo con las colecciones? Incluso en los idiomas que le permiten omitir los últimos puntos y comas y comas, a la comunidad generalmente no le gusta. A la comunidad de Perl, por ejemplo, no parece gustarle omitir punto y coma, excluir frases. Aplican eso a las comas también.

No omita comas en colecciones multilínea por la misma razón por la que no omite puntos y comas para bloques de código multilínea. Quiero decir, no lo harías incluso si el idioma lo permitiera, ¿verdad? ¿Correcto?

La razón es trivial: facilidad para agregar / eliminar líneas.

Imagine el siguiente código:

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

Ahora, puede agregar / eliminar elementos fácilmente a la lista sin tener que agregar / eliminar la coma final a veces.

A diferencia de otras respuestas, realmente no creo que la facilidad de generar la lista sea una razón válida: después de todo, es trivial que el código ponga en un caso especial la última (o primera) línea. Los generadores de código se escriben una vez y se usan muchas veces.

Permite que cada línea siga la misma forma. En primer lugar, esto hace que sea más fácil agregar nuevas filas y que un sistema de control de versiones rastree el cambio de manera significativa y también le permite analizar el código más fácilmente. No puedo pensar en una razón técnica.

Esto está permitido para proteger de los errores causados ​​por mover elementos en una larga lista.

Por ejemplo, supongamos que tenemos un código similar a este.

#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;
    }
}

Y es genial, ya que muestra la trilogía original de los sitios de Stack Exchange.

Stack Overflow
Super User
Server Fault

Pero hay un problema con eso. Verá, el pie de página en este sitio web muestra Falla del servidor antes del Superusuario. Mejor arreglar eso antes de que alguien se dé cuenta.

#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;
    }
}

Después de todo, mover las líneas no podría ser tan difícil, ¿verdad?

Stack Overflow
Server FaultSuper User

Lo sé, no hay un sitio web llamado "Server FaultSuper User", pero nuestro compilador afirma que existe. Ahora, el problema es que C tiene una función de concatenación de cadenas, que le permite escribir dos cadenas entre comillas dobles y concatenarlas sin usar nada (un problema similar también puede ocurrir con los enteros, ya que el -signo tiene múltiples significados).

¿Y si la matriz original tuviera una coma inútil al final? Bueno, las líneas se moverían, pero ese error no habría sucedido. Es fácil perderse algo tan pequeño como una coma. Si recuerda poner una coma después de cada elemento de la matriz, tal error simplemente no puede suceder. No querrá perder cuatro horas depurando algo, hasta que encuentre que la coma es la causa de sus problemas .

Como muchas cosas, la coma final en un inicializador de matriz es una de las cosas que C ++ heredó de C (y tendrá que soportar para siempre). Una vista totalmente diferente de las que se encuentran aquí se menciona en el libro "Deep C secrets" .

Luego de un ejemplo con más de una "paradoja de coma":

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? */
};

leemos :

... que coma final después de que el inicializador final no es un error tipográfico, pero un bache en la sintaxis prorrogados de C aborigen . Su presencia o ausencia está permitida pero no tiene importancia . La justificación alegada en la justificación de ANSI C es que facilita la generación automatizada de C. El reclamo sería más creíble si se permitieran las comas finales en cada lista separada por comas , como en las declaraciones de enumeración o en los declaradores de variables múltiples en una sola declaración. Ellos no son.

... para mí esto tiene más sentido

Además de la generación de código y la facilidad de edición, si desea implementar un analizador sintáctico, este tipo de gramática es más simple y fácil de implementar. C # sigue esta regla en varios lugares en los que hay una lista de elementos separados por comas, como los elementos en una enumdefinición.

Facilita la generación de código, ya que solo necesita agregar una línea y no necesita tratar de agregar la última entrada como si fuera un caso especial. Esto es especialmente cierto cuando se usan macros para generar código. Hay un impulso para tratar de eliminar la necesidad de macros del lenguaje, pero gran parte del lenguaje evolucionó de la mano con las macros disponibles. La coma adicional permite definir y usar macros como las siguientes:

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

Uso:

LIST_BEGIN
   LIST_ENTRY(1)
   LIST_ENTRY(2)
LIST_END

Es un ejemplo muy simplificado, pero a menudo las macros usan este patrón para definir cosas como mapas y tablas de despacho, mensaje, evento o traducción. Si no se permitía una coma al final, necesitaríamos un especial:

#define LIST_LAST_ENTRY(x) x

y eso sería muy incómodo de usar.

De modo que cuando dos personas agregan un nuevo elemento en una lista en ramas separadas, Git puede combinar los cambios correctamente, ya que Git funciona de forma lineal.

Si usa una matriz sin una longitud especificada, VC ++ 6.0 puede identificar automáticamente su longitud, por lo que si usa "int a [] = {1,2,};" la longitud de a es 3, pero la última no ' t inicializado, puedes usar "cout <