C ++ 14 aggiunge nuove parole chiave a C ++?


103

Il Comitato per gli standard C ++ tende a evitare di aggiungere nuove parole chiave al linguaggio, ma con C ++ 11 non è stato così. Qualche esempio:

constexpr
decltype
thread_local
auto // New usage
noexcept
nullptr
static_assert
alignof
alignas

Sono state introdotte nuove parole chiave con C ++ 14?

Risposte:


135

Tabella 4 (parole chiave) in N3936 (C ++ 14):

alignas           continue          friend            register          true
alignof           decltype          goto              reinterpret_cast  try
asm               default           if                return            typedef
auto              delete            inline            short             typeid
bool              do                int               signed            typename
break             double            long              sizeof            union
case              dynamic_cast      mutable           static            unsigned
catch             else              namespace         static_assert     using
char              enum              new               static_cast       virtual
char16_t          explicit          noexcept          struct            void
char32_t          export            nullptr           switch            volatile
class             extern            operator          template          wchar_t
const             false             private           this              while
constexpr         float             protected         thread_local
const_cast        for               public            throw

Tabella 4 in N3337 (C ++ 11):

alignas           continue          friend            register          true
alignof           decltype          goto              reinterpret_cast  try
asm               default           if                return            typedef
auto              delete            inline            short             typeid
bool              do                int               signed            typename
break             double            long              sizeof            union
case              dynamic_cast      mutable           static            unsigned
catch             else              namespace         static_assert     using
char              enum              new               static_cast       virtual
char16_t          explicit          noexcept          struct            void
char32_t          export            nullptr           switch            volatile
class             extern            operator          template          wchar_t
const             false             private           this              while
constexpr         float             protected         thread_local
const_cast        for               public            throw

... che è un modo prolisso per dire "no".

( overridee finalsono "identificatori con un significato speciale" e sono elencati nella Tabella 3; andecc. sono "rappresentazioni alternative ... per alcuni operatori e segni di punteggiatura" e sono elencati nella Tabella 5. Nessuna delle due tabelle è cambiata tra C ++ 11 e C ++ 14.)


2
Direi che è perché sono inseriti nello spazio dei nomi globale di ogni unità di traduzione. (Sì, puoi chiedere perché è così, e poi bene ...)
R. Martinho Fernandes

2
La registerparola chiave è ancora utile o utilizzata nel nuovo codice C ++ 11?
Walter

2
@Walter È comunque deprecato e ampiamente ignorato dai compilatori.
TC

1
I token alternativi per gli operatori logici non sono menzionati in quelle tabelle? Non sono parole chiave C ++?
Nikos Athanasiou

1
@NikosAthanasiou, c'è un tavolo per quelli proprio sotto questo IIRC.
chris

85

Pubblico questa risposta allo scopo di fornire strumenti per trovare risposte a domande simili.

La bozza standard è attualmente conservata in un repository GitHub pubblico. Ciò significa che puoi porre questa domanda a GitHub stesso!

La tabella delle parole chiave si trova nel file source/lex.tex. Se gli dai una colpa, possiamo scoprire che l' ultima modifica alla tabella delle parole chiave è avvenuta nell'agosto 2011 (in realtà è il primo commit: quella tabella non è cambiata da quando il repository è diventato attivo nel periodo C ++ 11 era in fase di finalizzazione).

In alternativa possiamo chiedere a GitHub di confrontare le due bozze inviate per il ballottaggio per entrambe le versioni dello standard: N3337 e N3936. Una differenza tra questi due mostra che le modifiche a lex.texnon hanno cambiato nulla nella tabella delle parole chiave.


1
Grazie per questo! Sembra che non siano ancora stati apportati cambiamenti a oggi.
sbi

34

Nessuna nuova parola chiave verrà aggiunta con C ++ 14. Ciò non sorprende in quanto C ++ 14 è inteso come un piccolo aggiornamento a C ++ 11 principalmente coinvolto nella pulizia dei bug e nell'apportare piccoli miglioramenti a basso impatto. Il prossimo cambiamento importante sarà probabilmente il C ++ "17", dove mi aspetto di nuovo nuove parole chiave.

Il Comitato per gli standard C ++ tende a evitare di aggiungere nuove parole chiave al linguaggio, ma con C ++ 11 non è stato così.

Penso che valga la pena considerare il motivo per cui il comitato evita di aggiungere nuove parole chiave (e incidentalmente perché sbagli a includerle autonel tuo elenco). Il problema principale con le nuove parole chiave è che in C ++ non è possibile utilizzare una parola chiave come identificatore, il che significa che l'aggiunta di una nuova parola chiave interrompe il codice esistente. Repurposing auto, poi, non rompere la loro regola, perché nessun codice esistente potrebbe usare autocome un identificatore in ogni caso .

Quindi, per accettare una nuova parola chiave, deve esserci una giustificazione che superi il costo di un potenziale conflitto con il codice esistente e nessun modo sensato per implementare la stessa cosa senza una nuova parola chiave. Nel caso di C ++ 11, il comitato ha accettato alcune proposte che richiedevano nuove parole chiave poiché riteneva che il vantaggio superasse il costo non perché non odiassero aggiungere nuove parole chiave.

È anche il motivo per cui, se guardi l'elenco che hai fornito, ognuna è una parola chiave composta poiché riduce la possibilità che si scontrino con gli identificatori esistenti.


1
"C ++ '17' dove mi sarei aspettato nuove parole chiave ancora una volta.": C ++ alla fine smetterà di crescere?
Giorgio

2
@Giorgio Il software e l'hardware alla fine smetteranno di evolversi? Il grande dilemma qui è se puoi prendere una decisione coraggiosa e buttare via la "vecchia" sintassi, rompere il vecchio codice e procedere solo con la parte evoluta del linguaggio. Python prova a farlo
Lorah Attkins

2
@NorahAttkins: Chiaramente il software deve evolversi, ma far crescere una lingua indefinitamente non è l'unica soluzione: quando una lingua è matura per una certa nicchia, puoi sempre rompere la compatibilità e iniziare una nuova lingua per soddisfare le esigenze di nuove nicchie. Python è un esempio. Altri esempi sono C ++ -> Java, Java -> Scala, Common Lisp -> Clojure, C ++ -> D.Alcuni linguaggi crescono indefinitamente perché la loro comunità è convinta che la loro lingua preferita sia l'unica vera lingua e lo vogliono per essere adatto a tutte le aree di applicazione possibili. Ovviamente questa aspettativa non è realistica.
Giorgio
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.