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 написання походження залишається.

і ми можемо перейти до обґрунтування С99, щоб побачити, чому це було дозволено в С, і в ньому сказано:

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 Overflow
Super User
Server Fault

Але з цим є одна проблема. Розумієте, колонтитул на цьому веб-сайті показує помилку сервера перед Super User. Краще виправте це, перш ніж хтось помітить.

#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

Я знаю, немає веб-сайту під назвою "Сервер FaultSuper User", але наш компілятор стверджує, що він існує. Тепер, проблема полягає в тому, що C має функцію конкатенації рядків, яка дозволяє записати дві подвійні цитати рядків і об'єднати їх, не використовуючи нічого (подібна проблема може траплятися і з цілими числами, як- знак має багато значень).

А що робити, якщо в початковому масиві в кінці була марна кома? Ну, лінії будуть переміщені, але такої помилки не було б. Легко пропустити щось таке маленьке, як кома. Якщо ви пам'ятаєте ставити кому після кожного елемента масиву, така помилка просто не може статися. Ви б не хотіли витрачати чотири години на щось налагодження, поки ви не знайдете кома - це причина ваших проблем .

Як і багато речей, кінцева кома в ініціалізаторі масиву є однією з речей 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? */
};

ми читаємо :

... , що Кома після остаточного ініціалізатор не помилка, але сплеск в синтаксисі , перенесений з аборигенного C . Його наявність або відсутність дозволено, але не має значення . Обгрунтування, заявлене в обґрунтуванні ANSI C, полягає в тому, що це полегшує автоматизовану генерацію C. Заява може бути більш достовірною, якби пропуски косів були дозволені у кожному списку , який оцінюється комами , наприклад у перерахунках перерахунків, або кількох деклараторах змінних в одній декларації. Вони не.

... для мене це має більше сенсу

Окрім створення коду та легкості редагування, якщо ви хочете реалізувати аналізатор, цей тип граматики простіший та легший у здійсненні. 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, але останній hasn " t ініціалізовано, ви можете використовувати "cout <