¿C ++ 14 agrega nuevas palabras clave a C ++?


103

El Comité de Estándares de C ++ tiende a evitar agregar nuevas palabras clave al lenguaje, pero con C ++ 11 ese no fue el caso. Algunos ejemplos:

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

¿Se han introducido nuevas palabras clave con C ++ 14?

Respuestas:


135

Tabla 4 (Palabras clave) en 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

Tabla 4 en 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

... que es una forma larga de decir "no".

( overridey finalson "identificadores con significado especial" y se enumeran en la Tabla 3; andetc. son "representaciones alternativas ... para ciertos operadores y puntuadores" y se enumeran en la Tabla 5. Ninguna tabla cambió entre C ++ 11 y C ++ 14.)


2
Yo diría que eso se debe a que se colocan en el espacio de nombres global de cada unidad de traducción. (Sí, puedes preguntar por qué es así, y luego bueno ...)
R. Martinho Fernandes

2
¿La registerpalabra clave sigue siendo útil o se utiliza en el nuevo código C ++ 11?
Walter

2
@Walter Está en desuso y de todos modos los compiladores lo ignoran.
TC

1
¿Los tokens alternativos para operadores lógicos no se mencionan en esas tablas? ¿No son palabras clave de C ++?
Nikos Athanasiou

1
@NikosAthanasiou, hay una mesa para los que están justo debajo de este IIRC.
chris

85

Estoy publicando esta respuesta con el fin de brindar herramientas para encontrar respuestas a preguntas similares.

El borrador estándar se mantiene actualmente en un repositorio público de GitHub. ¡Eso significa que puedes hacerle esta pregunta a GitHub!

La tabla de palabras clave está en el archivo source/lex.tex. Si le echa la culpa, podemos encontrar que el último cambio en la tabla de palabras clave tuvo lugar en agosto de 2011 (en realidad, es la primera confirmación: esa tabla no ha cambiado desde que el repositorio entró en funcionamiento alrededor de C ++ 11 estaba siendo finalizado).

Alternativamente, podemos pedirle a GitHub que compare los dos borradores que se enviaron para votación para ambas versiones del estándar: N3337 y N3936. Una diferencia entre esos dos muestra que los cambios en lex.texno cambiaron nada en la tabla de palabras clave.


1
¡Gracias por esto! Parece que todavía no ha habido cambios a partir de hoy.
sbi

34

No se agregarán nuevas palabras clave con C ++ 14. Esto no es sorprendente, ya que C ++ 14 está pensado como una pequeña actualización a C ++ 11 principalmente involucrada en la limpieza de errores y la realización de pequeñas mejoras de bajo impacto. Es probable que el próximo cambio importante sea C ++ '17', donde esperaría nuevas palabras clave una vez más.

El Comité de Estándares de C ++ tiende a evitar agregar nuevas palabras clave al lenguaje, pero con C ++ 11 ese no fue el caso.

Creo que vale la pena considerar por qué el comité evita agregar nuevas palabras clave (y, de manera coincidente, por qué se equivoca al incluirlo autoen su lista). El principal problema con las palabras clave nuevas es que en C ++ no se puede usar una palabra clave como identificador, lo que significa que agregar una palabra clave nueva rompe el código existente. Reutilizar auto, entonces, no rompe su regla porque ningún código existente podría usarse autocomo identificador de todos modos .

Entonces, para aceptar una nueva palabra clave, debe haber una justificación que supere el costo de un posible conflicto con el código existente y no hay una forma sensata de implementar lo mismo sin una nueva palabra clave. En el caso de C ++ 11, el comité aceptó algunas propuestas que requerían nuevas palabras clave, ya que sentían que el beneficio superaba el costo, no porque no odien agregar nuevas palabras clave.

También es la razón por la que, si miras la lista que proporcionaste, cada una es una palabra clave compuesta, ya que eso reduce la posibilidad de que entren en conflicto con los identificadores existentes.


1
"C ++ '17' donde esperaría nuevas palabras clave una vez más": ¿C ++ finalmente dejará de crecer?
Giorgio

2
@Giorgio ¿Dejarán de evolucionar el software y el hardware? El gran dilema aquí es si puede tomar una decisión audaz y deshacerse de la sintaxis "antigua", romper el código antiguo y proceder solo con la parte evolucionada del lenguaje. Python intenta hacer eso
Lorah Attkins

2
@NorahAttkins: Claramente, el software debe evolucionar, pero hacer crecer un idioma indefinidamente no es la única solución: cuando un idioma está maduro para un determinado nicho, siempre se puede romper la compatibilidad y comenzar un nuevo lenguaje para satisfacer las necesidades de nuevos nichos. Python es un ejemplo. Otros ejemplos son C ++ -> Java, Java -> Scala, Common Lisp -> Clojure, C ++ -> D. Algunos lenguajes crecen indefinidamente porque su comunidad está convencida de que su lenguaje favorito es el único lenguaje verdadero y lo quieren para adaptarse a todas las áreas de aplicación posibles. Por supuesto, esta expectativa no es realista.
Giorgio
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.