int a [] = {1,2,}; Dziwny przecinek dozwolony. Jakiś konkretny powód?

Może nie jestem z tej planety, ale wydaje mi się, że następujący błąd powinien być błędem składni:

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

Ale nie jest. Byłem zaskoczony, gdy ten kod został skompilowany w Visual Studio, ale nauczyłem się nie ufać kompilatorowi MSVC, jeśli chodzi o zasady C ++, więc sprawdziłem ten standard i jest on również dozwolony. Możesz zobaczyć 8.5.1 dla reguł gramatyki, jeśli mi nie wierzysz.

Dlaczego to jest dozwolone? To może być głupie bezużyteczne pytanie, ale chcę, żebyś zrozumiał, dlaczego pytam. Zrozumiałbym, gdyby był to pod-przypadek ogólnej reguły gramatycznej - postanowili nie utrudniać gramatyki ogólnej po prostu nie dopuszczać zbędnego przecinka na końcu listy inicjalizującej. Ale nie, dodatkowy przecinek jest wyraźnie dozwolony. Na przykład niedozwolone jest umieszczanie nadmiarowego przecinka na końcu listy argumentów wywołania funkcji (gdy funkcja przyjmuje ...), co jest normalne .

Czy zatem istnieje jakiś szczególny powód, dla którego ta nadmiarowa przecinek jest wyraźnie dozwolona?

Ułatwia generowanie kodu źródłowego, a także pisanie kodu, który można łatwo rozszerzyć w późniejszym terminie. Zastanów się, co jest wymagane, aby dodać dodatkowy wpis do:

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

... musisz dodać przecinek do istniejącej linii i dodać nową linię. Porównaj to z przypadkiem, w którym trzy mają już przecinek, po prostu musisz dodać linię. Podobnie, jeśli chcesz usunąć linię, możesz to zrobić, nie martwiąc się o to, czy jest to ostatnia linia, czy nie, i możesz zmienić kolejność linii bez zbędnego wprowadzania przecinków. Zasadniczo oznacza to jednolitość w traktowaniu linii.

Pomyśl teraz o wygenerowaniu kodu. Coś w stylu (pseudo-kod):

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

Nie musisz się martwić, czy zapisywany element jest pierwszym, czy ostatnim. O wiele prostsze.

Jest to przydatne, jeśli robisz coś takiego:

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

Myślę, że łatwość użycia dla programisty.

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

Dodatkowo, jeśli z jakiegokolwiek powodu masz narzędzie, które wygenerowało dla ciebie kod; narzędzie nie musi dbać o to, czy jest to ostatni element w inicjalizacji, czy nie.

Zawsze zakładałem, że ułatwia to dodanie dodatkowych elementów:

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

po prostu staje się:

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

w późniejszym terminie.

Wszystko, co wszyscy mówią o łatwości dodawania / usuwania / generowania linii, jest poprawne, ale prawdziwym miejscem, w którym ta składnia się świeci, jest łączenie plików źródłowych. Wyobraź sobie, że masz tę tablicę:

int ints[] = {
    3,
    9
};

Załóżmy, że sprawdziłeś ten kod w repozytorium.

Następnie twój kolega edytuje go, dodając do końca:

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

I jednocześnie edytujesz go, dodając na początku:

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

Semantycznie tego rodzaju operacje (dodawanie na początku, dodawanie na końcu) powinny być całkowicie bezpieczne, a twoje oprogramowanie do wersji (mam nadzieję, że git) powinno być w stanie zautomatyzować. Niestety tak nie jest, ponieważ twoja wersja nie ma przecinka po 9, a twój kumpel ma. Podczas gdy gdyby oryginalna wersja miała końcową liczbę 9, automatycznie by się pojawiły.

Zatem moja ogólna zasada brzmi: użyj przecinka końcowego, jeśli lista obejmuje wiele linii, nie używaj go, jeśli lista znajduje się w jednej linii.

Przecinek końcowy Uważam, że jest dozwolony ze względu na kompatybilność wsteczną. Istnieje wiele istniejących kodów, głównie generowanych automatycznie, co powoduje wstawienie przecinka. Ułatwia napisanie pętli bez specjalnych warunków na końcu. na przykład

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

Praktycznie nie ma żadnej przewagi dla programisty.

PS Chociaż w ten sposób łatwiej jest wygenerować kod automatycznie, zawsze starałem się nie wstawiać przecinka, wysiłki są minimalne, poprawia się czytelność, a to jest ważniejsze. Piszesz kod raz, czytasz go wiele razy.

O ile mi wiadomo, jest to jeden z powodów, dla których automatyczne generowanie kodu powinno być proste; nie potrzebujesz żadnej specjalnej obsługi ostatniego elementu.

Ułatwia to generowanie kodów, które wypluwają tablice lub wyliczenia.

Wyobrażać sobie:

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

Tj. Nie ma potrzeby specjalnego obchodzenia się z pierwszym lub ostatnim elementem, aby uniknąć plucia końcowego przecinka.

Jeśli na przykład generator kodu jest napisany w języku Python, łatwo jest uniknąć plucia końcowego przecinka za pomocą str.join()funkcji:

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

Dziwi mnie, że przez cały ten czas nikt nie zacytował Annotated C ++ Reference Manual ( ARM ), mówi on o [dcl.init] z naciskiem na mój:

Istnieje wyraźnie zbyt wiele oznaczeń do inicjalizacji, ale wydaje się, że każda z nich dobrze pasuje do określonego stylu użycia. W = {initializer_list OPT} oznaczenie zostało odziedziczone C i służy również do inicjalizacji struktur danych i tablic. [...]

chociaż gramatyka ewoluowała od czasu napisania ARM, pochodzenie pozostaje.

i możemy przejść do uzasadnienia C99, aby zobaczyć, dlaczego było to dozwolone w C, i mówi:

K&R zezwala na końcowy przecinek w inicjalizatorze na końcu listy inicjalizacyjnej. Standard zachował tę składnię, ponieważ zapewnia elastyczność dodawania lub usuwania elementów z listy inicjalizującej i upraszcza generowanie maszynowe takich list.

Widzę jeden przypadek użycia, który nie został wymieniony w innych odpowiedziach, nasze ulubione makra:

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

Dodanie makr do obsługi ostatniego ,byłoby dużym bólem. Przy tej małej zmianie w składni zarządzanie tym jest trywialne. Jest to ważniejsze niż kod generowany maszynowo, ponieważ zwykle łatwiej jest to zrobić w pełnym języku Turinga niż w bardzo ograniczonym preprocesorze.

Jedynym językiem, w którym - w praktyce * - jest niedozwolony, jest JavaScript i powoduje on niezliczoną ilość problemów. Na przykład, jeśli skopiujesz i wkleisz wiersz ze środka tablicy, wkleisz go na końcu i zapomnisz usunąć przecinek, Twoja witryna zostanie całkowicie zepsuta dla użytkowników IE.

* Teoretycznie jest to dozwolone, ale Internet Explorer nie przestrzega standardu i traktuje go jako błąd

Jest to łatwiejsze dla maszyn, tj. Parsowania i generowania kodu. Jest to również łatwiejsze dla ludzi, tj. Modyfikacja, komentowanie i wizualna elegancja dzięki spójności.

Zakładając C, czy napisałbyś następujące?

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

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

    return EXIT_SUCCESS
}

Nie. Nie tylko dlatego, że końcowe stwierdzenie jest błędem, ale także dlatego, że jest niespójne. Dlaczego więc to samo dotyczy kolekcji? Nawet w językach, w których można pominąć ostatnie średniki i przecinki, społeczność zwykle tego nie lubi. Na przykład społeczność Perla nie lubi pomijać średników, poza linijkami. Stosują to również do przecinków.

Nie pomijaj przecinków w zbiorach wielowierszowych z tego samego powodu, dla którego nie odrzucasz średników dla wielowierszowych bloków kodu. To znaczy, nie zrobiłbyś tego, nawet gdyby język na to pozwalał, prawda? Dobrze?

Powód jest trywialny: łatwość dodawania / usuwania linii.

Wyobraź sobie następujący kod:

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

Teraz możesz łatwo dodawać / usuwać elementy do listy bez konieczności dodawania / usuwania końcowego przecinka.

W przeciwieństwie do innych odpowiedzi, tak naprawdę nie uważam, że łatwość generowania listy jest ważnym powodem: w końcu kod zajmuje specjalne miejsce w ostatniej (lub pierwszej) linii. Generatory kodu są pisane raz i używane wiele razy.

Pozwala każdej linii na przyjęcie tego samego formularza. Po pierwsze, ułatwia to dodawanie nowych wierszy i pozwala systemowi kontroli wersji w znaczący sposób śledzić zmianę, a także umożliwia łatwiejszą analizę kodu. Nie mogę wymyślić przyczyny technicznej.

Pozwala to zabezpieczyć się przed błędami powodowanymi przez przenoszenie elementów na długiej liście.

Załóżmy na przykład, że mamy kod wyglądający tak.

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

I jest świetny, ponieważ pokazuje oryginalną trylogię witryn Stack Exchange.

Stack Overflow
Super User
Server Fault

Ale jest z tym jeden problem. Widzisz, stopka na tej stronie pokazuje awarię serwera przed superużytkownikiem. Lepiej to napraw, zanim ktokolwiek zauważy.

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

W końcu przesuwanie linii nie może być takie trudne, prawda?

Stack Overflow
Server FaultSuper User

Wiem, że nie ma witryny o nazwie „Server FaultSuper User”, ale nasz kompilator twierdzi, że istnieje. Problem polega na tym, że C ma funkcję konkatenacji łańcuchów, która pozwala napisać dwa łańcuchy z podwójnym cudzysłowem i połączyć je przy użyciu niczego (podobny problem może się również zdarzyć z liczbami całkowitymi, ponieważ -znak ma wiele znaczeń).

A co jeśli oryginalna tablica miała na końcu bezużyteczny przecinek? Cóż, linie byłyby przesuwane, ale taki błąd nie miałby miejsca. Łatwo przeoczyć coś tak małego jak przecinek. Jeśli pamiętasz, aby po każdym elemencie wstawić przecinek, taki błąd po prostu nie może się zdarzyć. Nie chcesz tracić czterech godzin na debugowanie czegoś, dopóki nie znajdziesz przecinka, który jest przyczyną twoich problemów .

Podobnie jak wiele innych, przecinek końcowy w inicjalizatorze tablicowym jest jedną z rzeczy odziedziczonych przez C ++ po C (i będzie musiał być obsługiwany na zawsze). Pogląd całkowicie odmienny od przedstawionego tutaj jest wspomniany w książce „Deep C Secrets” .

Oto przykład z kilkoma „paradoksami przecinków”:

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

czytamy :

... że trailing przecinek po ostatnim inicjatora nie jest literówka, ale blip w składni przeniesione z rodowity C . Jego obecność lub brak jest dozwolony, ale nie ma znaczenia . Uzasadnieniem uzasadnienia ANSI C jest to, że ułatwia zautomatyzowane generowanie C. Twierdzenie byłoby bardziej wiarygodne, gdyby końcowe przecinki były dozwolone na każdej liście rozdzielanej przecinkami , na przykład w deklaracjach wyliczonych lub w wielu deklaratorach zmiennych w jednej deklaracji. Oni nie są.

... dla mnie ma to większy sens

Oprócz łatwości generowania i edycji kodu, jeśli chcesz zaimplementować analizator składni, ten typ gramatyki jest prostszy i łatwiejszy do wdrożenia. C # przestrzega tej zasady w kilku miejscach, w których znajduje się lista elementów oddzielonych przecinkami, takich jak elementy w enumdefinicji.

Ułatwia generowanie kodu, ponieważ wystarczy dodać tylko jeden wiersz i nie trzeba traktować dodawania ostatniego wpisu, jakby to był szczególny przypadek. Jest to szczególnie prawdziwe w przypadku używania makr do generowania kodu. Próbuje się wyeliminować potrzebę używania makr z danego języka, ale wiele języków ewoluowało równolegle z dostępnymi makrami. Dodatkowy przecinek umożliwia zdefiniowanie i użycie makr, takich jak następujące:

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

Stosowanie:

LIST_BEGIN
   LIST_ENTRY(1)
   LIST_ENTRY(2)
LIST_END

To bardzo uproszczony przykład, ale często ten wzór jest używany przez makra do definiowania takich rzeczy, jak mapy i tabele wysyłki, wiadomości, zdarzenia lub tłumaczenia. Jeśli przecinek nie byłby dozwolony na końcu, potrzebowalibyśmy specjalnego:

#define LIST_LAST_ENTRY(x) x

i byłoby to bardzo niewygodne w użyciu.

Tak więc, gdy dwie osoby dodają nowy element do listy w oddzielnych gałęziach, Git może poprawnie scalić zmiany, ponieważ Git działa w trybie liniowym.

Jeśli użyjesz tablicy bez określonej długości, VC ++ 6.0 może automatycznie zidentyfikować jej długość, więc jeśli użyjesz „int a [] = {1,2,};” długość a wynosi 3, ale ostatnia nie ma „ t został zainicjowany, możesz użyć „cout <