Чому потворні ключові слова в C11?

Зараз я читаю проект специфікації C11. Нові введені ключові слова: _Bool, _Alignof, _Atomicусі відчувають себе розширеними, а не стандартними зарезервованими ключовими словами struct, union, int.

Я розумію, що стандарт в основному складається з стандартизованих розширень ... але все-таки це жахливо! Можливо, ми скоро закінчимось __Long_Long_Reallylong_Integer_MSVC_2020_tповзанням у стандарті!

Чи є відстала сумісність нестандартного коду єдиною причиною нового стилю ключових слів?

c keywords

— Vorac
джерело

Ні, я б не переймався подібними дійсно довгими типами. Кількість комбінацій літер і цифр _, az, AZ і 0-9 означає, що вони, мабуть, просто будуть короткими і важко запам’ятати.

— Ніл

Синонім приємного вигляду кожного ключового слова часто визначається у відповідному стандартному файлі заголовка бібліотеки. Наприклад, будь-який <stdbool.h>файл заголовка реалізації C11 повинен містити макрос попереднього процесу, наприклад #define bool _Bool. Це акуратне рішення, оскільки воно зберігає зворотну сумісність, але дозволяє будь-якому новому коду, що включає новий файл заголовка, використовувати більш привабливий синтаксис.

— andrew.punnett

Відповіді:

Я думаю, що зворотна сумісність із ідеально стандартним кодом є важливішою причиною.

Якщо ви додасте ключове слово, яке, можливо, було використане в якості законного ідентифікатора в попередньому коді, ви створюєте масу больових відчуттів, можливих тонких помилок, особливо в мові С, якоюсь складними правилами розбору.

Якщо ці ідентифікатори десь використовувались як загальнодоступний інтерфейс, ви додаєте біль усім користувачам таких нещасних бібліотек, які, можливо, зовсім не використовують C, але викликають бібліотеку від Ruby, або Python тощо.

Ось чому нові ключові слова, мабуть, виглядатимуть не так, як приємні слова і більше схожі на хакерські хакі, які люди мають менші шанси вже використовувати для іншої мети.

— 9000
джерело

Слід зазначити, що питання стосувалося C, а не C ++, неважливо. Ваша відповідь охоплює причину того, що новий тип піддрукованого типу буде названий чимось, щоб уникнути використання конфлікту з користувацьким типом Boolу застарілому коді, який було прийнято вважати булевим, але ніколи фактично не є частиною стандарту С, тому припущення не є безпечним для зробити.

— Рамхаунд

@Ramhound, IMHO boolбув би більше в дусі С. Крім того, я не повністю переконаний у цій відповіді, оскільки некрасиві слова також могли використовуватися нестандартним кодом. І зміна стилю слів робить стандартні слова важче розпізнати з першого погляду.

— Ворак

@Vorac: Проблема полягає в тому, що якби boolдодати мову безумовно, то всі проекти, які мають власну (цілком законну) версію bool, припиняють збиратись. Це серйозно зашкодить прийняттю перегляду мови. Це причина, що всі нові ідентифікатори приймаються із зарезервованого набору (таким чином, починаючи з _[capital]). Оскільки також був великий попит на boolсебе, це було додано, як і typedef _Bool boolв <stdbool.h>.

— Барт ван Інген Шенау

@BartvanIngenSchenau - що дозволяє людям замінити власний typedef булевого значення на той, що міститься в межах, stdbool.hабо оновити свій власний typedef на новий тип, щоб підтримати їхній застарілий код.

— Рамхаунд

@Ramhound - люди зі змінними, які конфліктували з новими ключовими словами C11, також можуть "Так не використовувати?". Існує прапор компіляції std = xxx для запобігання будь-яких конфліктів з новими мовними стандартами.

— Скутер

Імена, що починаються з підкреслення та великої літери (і все, що має подвійне підкреслення), були зарезервовані для реалізації компілятора / стандартної бібліотеки в попередніх стандартах.

З зарезервованих ідентифікаторів C89 та C99:

Крім того, для виконавця зарезервовано всі зовнішні ідентифікатори, що починаються з підкреслення, а всі інші ідентифікатори, що починаються з підкреслення, після чого велика літера або підкреслення.

Тож теоретично ці нові ключові слова не повинні використовуватися в жодному коді, написаному раніше, і це призводить до кращої зворотної сумісності, ніж будь-яке просте ім'я, що, ймовірно, є єдиною причиною.

— Dotti
джерело

Ви повинні цитувати та, можливо, посилатися на відповідний розділ стандартів або називати його, щоб інші могли швидко перевірити вашу заяву. Це покращить вашу відповідь.

— SpaceTrucker