int a [] = {1,2,}; Странная запятая разрешена. Любая конкретная причина?

Возможно, я не с этой планеты, но мне кажется, что синтаксическая ошибка должна быть следующей:

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

Но это не так. Я был удивлен , когда этот код скомпилирован на Visual Studio, но я научился не доверять MSVC компилятор, насколько правила C ++ обеспокоены, так что я проверил стандарт и это допускается стандартом , а также. Вы можете увидеть 8.5.1 правила грамматики, если не верите мне.

Почему это разрешено? Это может быть глупый бесполезный вопрос, но я хочу, чтобы вы поняли, почему я спрашиваю. Если бы это был подслучайный случай общего правила грамматики, я бы понял - они решили не усложнять общую грамматику, просто запретив избыточную запятую в конце списка инициализатора. Но нет, дополнительная запятая явно разрешена. Например, не допускается иметь избыточную запятую в конце списка аргументов вызова функции (когда функция принимает ...), что является нормальным .

Итак, опять же, есть ли какая-то особая причина, по которой эта избыточная запятая явно разрешена?

Это облегчает генерацию исходного кода, а также написание кода, который может быть легко расширен позднее. Подумайте, что требуется для добавления дополнительной записи в:

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

... вы должны добавить запятую к существующей строке и добавить новую строку. Сравните это со случаем, когда тройка уже имеет запятую после нее, где вам просто нужно добавить строку. Аналогично, если вы хотите удалить строку, вы можете сделать это, не беспокоясь о том, является ли она последней или нет, и вы можете изменить порядок строк, не запутываясь в запятых. По сути, это означает, что в отношении к линиям есть единообразие.

Теперь подумайте о генерации кода. Что-то вроде (псевдокод):

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

Не нужно беспокоиться о том, является ли текущий элемент, который вы записываете, первым или последним. Гораздо проще

Это полезно, если вы делаете что-то вроде этого:

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

Простота использования для разработчика, я думаю.

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

Кроме того, если по какой-либо причине у вас был инструмент, который генерировал код для вас; инструмент не должен заботиться о том, является ли он последним элементом в инициализации или нет.

Я всегда предполагал, что это облегчает добавление дополнительных элементов:

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

просто становится:

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

впоследствии.

Все, что все говорят о легкости добавления / удаления / генерации строк, является правильным, но реальный смысл этого синтаксиса - объединение исходных файлов. Представьте, что у вас есть этот массив:

int ints[] = {
    3,
    9
};

И предположим, что вы проверили этот код в хранилище.

Затем ваш друг редактирует его, добавляя в конец:

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

И вы одновременно редактируете это, добавляя в начало:

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

Семантически эти виды операций (добавление в начало, добавление в конец) должны быть полностью безопасны для слияния, а программное обеспечение управления версиями (возможно, git) должно иметь возможность автоматического объединения. К сожалению, это не так, потому что у вашей версии нет запятой после 9, а у вашего собеседника - нет. Принимая во внимание, что, если бы у оригинальной версии был завершающий 9, они бы объединились.

Итак, мое правило: используйте запятую, если список занимает несколько строк, не используйте ее, если список находится на одной строке.

Конечная запятая, я считаю, разрешена по причинам обратной совместимости. Существует много существующего кода, в основном сгенерированного автоматически, который ставит запятую. Это облегчает написание цикла без особых условий в конце. например

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

Для программиста нет никаких преимуществ.

PS Хотя таким способом проще генерировать код, на самом деле я всегда старался не ставить конечную запятую, усилия минимальны, читаемость улучшена, и это важнее. Вы пишете код один раз, вы читаете его много раз.

Насколько мне известно, одна из причин, по которой это разрешено, заключается в простоте автоматической генерации кода; вам не нужно никакой специальной обработки для последнего элемента.

Это облегчает генераторы кода, которые выкладывают массивы или перечисления.

Представить:

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

Т.е. не нужно делать специальную обработку первого или последнего элемента, чтобы не выплевывать запятую.

Например, если генератор кода написан на Python, легко избежать разбрызгивания запятой, используя str.join()функцию:

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

Я удивлен, что за все это время никто не процитировал Аннотированное справочное руководство C ++ ( ARM ), в нем говорится следующее о [dcl.init] с акцентом на мое:

Очевидно, что слишком много обозначений для инициализации, но каждая, кажется, хорошо подходит для определенного стиля использования. В = {initializer_list, неавтоматические} обозначения было унаследованы от C и служит также для инициализации структур данных и массивов. [...]

хотя грамматика эволюционировала с момента написания ARM, происхождение остается.

и мы можем перейти к обоснованию C99, чтобы понять, почему это было разрешено в C, и там написано:

K & R позволяет использовать запятую в инициализаторе в конце списка инициализаторов. Стандарт сохранил этот синтаксис, поскольку он обеспечивает гибкость при добавлении или удалении элементов из списка инициализатора и упрощает машинное создание таких списков.

Я вижу один вариант использования, который не был упомянут в других ответах, наши любимые макросы:

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

Добавление макросов для обработки последних ,будет большой болью. С этим небольшим изменением синтаксиса этим тривиально управлять. И это более важно, чем машинно-сгенерированный код, потому что, как правило, гораздо проще сделать это в полном языке Тьюринга, чем очень ограниченный препроцессор.

Единственный язык, на котором это - на практике * - не допускается, - это Javascript, и это вызывает неисчислимое количество проблем. Например, если вы скопируете и вставите строку из середины массива, вставите ее в конце и забудете удалить запятую, тогда ваш сайт будет полностью поврежден для ваших посетителей IE.

* Теоретически это разрешено, но Internet Explorer не следует стандарту и рассматривает его как ошибку

Это проще для машин, то есть для анализа и генерации кода. Это также легче для людей, то есть модификация, комментирование и визуальная элегантность через последовательность.

Предполагая C, вы бы написали следующее?

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

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

    return EXIT_SUCCESS
}

Нет. Не только потому, что последнее утверждение является ошибкой, но и потому, что оно несовместимо. Так почему же то же самое с коллекциями? Даже в тех языках, которые позволяют пропустить последние точки с запятой и запятые, сообществу это обычно не нравится. Сообщество Perl, например, не любит опускать точки с запятой, кроме однострочных. Они также применяют это к запятым.

Не пропускайте запятые в многострочных коллекциях по той же причине, по которой вы не пропускаете точки с запятой для многострочных блоков кода. Я имею в виду, вы бы не сделали этого, даже если бы язык позволял это, верно? Правильно?

Причина тривиальна: простота добавления / удаления строк.

Представьте себе следующий код:

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

Теперь вы можете легко добавлять / удалять элементы в списке без необходимости иногда добавлять / удалять завершающую запятую.

В отличие от других ответов, я на самом деле не думаю, что легкость генерирования списка является веской причиной: в конце концов, тривиально, чтобы код специально выделил последнюю (или первую) строку. Генераторы кода пишутся один раз и используются много раз.

Это позволяет каждой строке следовать той же форме. Во-первых, это облегчает добавление новых строк и позволяет системе контроля версий осмысленно отслеживать изменения, а также позволяет легче анализировать код. Я не могу думать о технической причине.

Это позволяет защитить от ошибок, вызванных перемещением элементов в длинном списке.

Например, предположим, что у нас есть код, похожий на этот.

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

И это здорово, так как показывает оригинальную трилогию сайтов Stack Exchange.

Stack Overflow
Super User
Server Fault

Но есть одна проблема с этим. Видите ли, нижний колонтитул на этом сайте показывает сбой сервера перед суперпользователем. Лучше исправить это, прежде чем кто-нибудь заметит.

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

В конце концов, перемещение линий не может быть таким сложным, не так ли?

Stack Overflow
Server FaultSuper User

Я знаю, что нет сайта под названием «Server FaultSuper User», но наш компилятор утверждает, что он существует. Теперь проблема в том, что в C есть функция конкатенации строк, которая позволяет вам писать две строки в двойных кавычках и объединять их, не используя ничего (аналогичная проблема может возникнуть и с целыми числами, так как- знак имеет несколько значений).

А что если исходный массив имеет бесполезную запятую в конце? Ну, линии будут перемещаться, но такой ошибки не было бы. Легко пропустить что-то такое маленькое, как запятая. Если вы не забыли ставить запятую после каждого элемента массива, такой ошибки просто не может быть. Вы бы не хотели тратить четыре часа на отладку чего-либо, пока не обнаружите, что причиной ваших проблем является запятая .

Как и многие другие, конечная запятая в инициализаторе массива - это одна из вещей, наследуемых C ++ от C (и ее придется поддерживать всегда). Представление, совершенно отличное от представленного здесь , упоминается в книге «Секреты глубокой С» .

Вот пример с более чем одним «парадоксом запятой»:

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

мы читаем :

... эта запятая после финального инициализатора - не опечатка, а ошибка в синтаксисе, перенесенная с аборигенов Си . Его присутствие или отсутствие допускается, но не имеет значения . Обоснование, заявленное в обосновании ANSI, заключается в том, что оно облегчает автоматическую генерацию Си. Заявление было бы более правдоподобным, если бы в каждом списке с разделителями-запятыми были разрешены конечные запятые , например, в объявлениях enum или в нескольких деклараторах переменных в одном объявлении. Они не.

... для меня это имеет больше смысла

В дополнение к простоте генерации и редактирования кода, если вы хотите реализовать синтаксический анализатор, этот тип грамматики проще и проще в реализации. C # следует этому правилу в нескольких местах, где есть список разделенных запятыми элементов, таких как элементы в enumопределении.

Это облегчает генерацию кода, так как вам нужно добавить только одну строку и не нужно обрабатывать добавление последней записи, как будто это особый случай. Это особенно верно при использовании макросов для генерации кода. Есть попытка устранить необходимость в макросах из языка, но многие языки развивались рука об руку с доступными макросами. Дополнительная запятая позволяет определять и использовать такие макросы, как следующие:

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

Использование:

LIST_BEGIN
   LIST_ENTRY(1)
   LIST_ENTRY(2)
LIST_END

Это очень упрощенный пример, но часто этот шаблон используется макросами для определения таких вещей, как карты и таблицы отправки, сообщения, события или перевода. Если запятая не была разрешена в конце, нам нужно специальное:

#define LIST_LAST_ENTRY(x) x

и это было бы очень неудобно в использовании.

Таким образом, когда два человека добавляют новый элемент в список в отдельных ветвях, Git может правильно объединить изменения, потому что Git работает на линейной основе.

Если вы используете массив без заданной длины, VC ++ 6.0 может автоматически определить его длину, поэтому если вы используете "int a [] = {1,2,};" длина a равна 3, но последний не имеет ' t был инициализирован, вы можете использовать "cout <