Perché le brutte parole chiave in C11?


15

Attualmente sto leggendo una bozza della specifica C11. Le nuove parole chiave introdotte: _Bool, _Alignof, _Atomictutte sembrano estensioni personalizzate, invece di parole chiave standard riservate come struct, union, int.

Mi rendo conto che lo standard consiste essenzialmente in estensioni standardizzate ... ma comunque, è terribile! Forse finiremo presto per __Long_Long_Reallylong_Integer_MSVC_2020_tinsinuarsi nello standard!

La retrocompatibilità del codice non standard è l'unica ragione del nuovo stile delle parole chiave?


2
No, non mi preoccuperei di tipi così lunghi. Il numero di combinazioni di lettere e numeri di _, az, AZ e 0-9 significa che probabilmente sarebbero solo brevi e difficili da ricordare.
Neil

2
Un sinonimo dall'aspetto migliore per ogni parola chiave è spesso definito nel file di intestazione della libreria standard pertinente. Ad esempio, qualsiasi <stdbool.h>file di intestazione dell'implementazione C11 deve includere una macro del preprocessore come #define bool _Bool. Questa è una soluzione accurata poiché mantiene la compatibilità con le versioni precedenti, ma consente a qualsiasi nuovo codice, che include il nuovo file di intestazione, di utilizzare la sintassi più interessante.
andrew.punnett,

Risposte:


20

Immagino che la retrocompatibilità con un codice perfettamente standard sia una ragione più importante.

Se aggiungi una parola chiave che potrebbe essere stata utilizzata come identificatore legittimo nel codice precedente, crei una tonnellata di dolore, di possibili errori sottili, specialmente in C, un linguaggio con regole di analisi in qualche modo complicate.

Se questi identificatori sono stati usati come interfaccia pubblica da qualche parte, aggiungi dolore a tutti gli utenti di tali sfortunate librerie, che potrebbero non usare affatto C, ma chiamare la libreria da Ruby, o Python, ecc.

Ecco perché le nuove parole chiave sono destinate ad apparire meno come belle parole e più come hack imbullonati che le persone hanno minori possibilità di utilizzare già per un altro scopo.


Va sottolineato che la questione non riguardava C e C ++. La tua risposta copre il motivo per cui un nuovo tipo sovrastato verrebbe nominato come qualcosa per evitare di causare un conflitto con un tipo personalizzato Boolnel codice legacy che era ampiamente accettato come booleano ma che in realtà non faceva mai parte dello standard C, quindi il presupposto non è sicuro rendere.
Ramhound

1
@Ramhound, IMHO boolsarebbe più nello spirito di C. Inoltre, non sono del tutto convinto da questa risposta, poiché le parole brutte potrebbero anche essere state usate da un codice non standard. E cambiare lo stile delle parole rende le parole standard più difficili da riconoscere a colpo d'occhio.
Vorac,

6
@Vorac: il problema è che se boolfosse stato aggiunto incondizionatamente al linguaggio, tutti i progetti con una propria versione (perfettamente legittima) boolsmetterebbero di essere compilati. Ciò danneggerebbe gravemente l'accettazione della revisione della lingua. Questo è il motivo per cui tutti i nuovi identificatori vengono presi dall'insieme riservato (iniziando così con _[capital]). Poiché c'era anche una grande domanda per boolse stesso, questo è stato aggiunto come typedef _Bool boolin <stdbool.h>.
Bart van Ingen Schenau

1
@BartvanIngenSchenau - Che consente alle persone di sostituire il proprio typedef di un valore booleano con uno contenuto stdbool.ho aggiornare il proprio typedef con il nuovo tipo per supportare il loro codice legacy.
Ramhound

1
@Ramhound - le persone con variabili in conflitto con le nuove parole chiave C11 potrebbero anche "Quindi non usarlo?". C'è un flag di compilazione std = xxx per prevenire conflitti con i nuovi standard linguistici.
Scooter

8

I nomi che iniziano con un carattere di sottolineatura e una lettera maiuscola (e qualsiasi altra cosa con doppio carattere di sottolineatura) sono stati riservati per l'implementazione del compilatore / libreria standard negli standard precedenti.

Da identificatori riservati di C89 e C99:

Inoltre, per l'implementatore sono riservati tutti gli identificatori esterni che iniziano con un carattere di sottolineatura e tutti gli altri identificatori che iniziano con un carattere di sottolineatura seguito da una lettera maiuscola o un carattere di sottolineatura.

Quindi, in teoria, queste nuove parole chiave non dovrebbero essere utilizzate in nessun codice scritto prima e ciò porta a una migliore compatibilità con le versioni precedenti rispetto a qualsiasi nome semplice, che è probabilmente l'unica ragione.


4
Dovresti citare ed eventualmente collegare o nominare la sezione degli standard appropriati, in modo che altri possano verificare rapidamente la tua dichiarazione. Ciò migliorerà la tua risposta.
SpaceTrucker
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.