Почему список инициализаторов с зависающей запятой разрешен в C ++ 11? [Дубликат]

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

int ints[] = {
    3,
    9
};

И предположим, что вы проверили этот код в репозитории.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#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, вы могли бы написать следующее?

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

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

    return EXIT_SUCCESS
}

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

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

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

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

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

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 ++ унаследовал от C (и им придется поддерживать навсегда). В книге «Deep C secrets» упоминается вид, совершенно отличный от тех, что указаны здесь.

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

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

мы читаем:

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

... для меня это имеет смысл

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

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

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

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

в более позднюю дату.

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

#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

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

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

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

, хотя грамматика развилась с тех пор, как было написано ARM , происхождение остается.

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

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

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

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