resueltos - ¿Por qué los diseñadores de lenguaje C++ siguen reutilizando palabras clave?

ejemplos de programas en c++ pdf (5)

¿Cuál es el argumento principal a favor de reutilizar palabras clave cortas (y agregar significados dependientes del contexto) en lugar de simplemente agregar más palabras clave?

¿Es solo que desea evitar romper el código existente que ya puede estar usando una nueva palabra clave propuesta, o hay una razón más profunda?

La nueva "clase de enumeración" en C ++ 11 me hizo pensar en esto, pero esta es una pregunta de diseño de lenguaje general.

¿Es solo que desea evitar romper el código existente que ya puede estar usando una nueva palabra clave propuesta, o hay una razón más profunda?

No, esa es la razón.

Las palabras clave, por definición, siempre se consideran palabras clave dondequiera que aparezcan en la fuente, por lo que no se pueden usar para otros fines. Convertir una palabra clave en algo rompe cualquier código que pueda estar usando ese token como variable, función o nombre de tipo.

El comité C adopta un enfoque diferente y agrega nuevas palabras clave usando _Reservados nombres, por ejemplo, _Atomic , _Bool , y luego agrega un nuevo encabezado ( <stdatomic.h> , <stdbool.h> ) con una macro más agradable, para que pueda elegir si incluir el encabezado para obtener el nombre atomic o bool , pero no se declarará automáticamente y no romperá el código que ya está usando esos nombres.

Al comité de C ++ no le gustan las macros y quiere que sean palabras clave adecuadas, por lo tanto, reutilice las existentes (como auto ) o agregue "palabras clave" dependientes del contexto (que en realidad no son palabras clave, pero son "identificadores con significado especial "para que se puedan usar para otras cosas, como override ) o usar ortografías extrañas que es poco probable que decltype en conflicto con el código de usuario (como decltype lugar del tipo de extensión ampliamente compatible).

¿Es solo que desea evitar romper el código existente que ya puede estar usando una nueva palabra clave propuesta, o hay una razón más profunda?

Por definición, una palabra clave es un token especial que no se puede usar en ningún otro lugar; Como resultado, la introducción de una palabra clave rompe cualquier código que haya utilizado un identificador con la ortografía dada.

Algunos idiomas usan el término palabra clave contextual para referirse a la ortografía que solo se interpreta como palabra clave en contextos específicos. Si no se pudo utilizar previamente un identificador "salvaje" en este contexto, se garantiza que la introducción de la palabra clave contextual no romperá el código existente. Por ejemplo, dado que ningún identificador puede aparecer inmediatamente después del paréntesis de cierre en una firma de función, este es un lugar donde se pueden introducir las llamadas palabras clave contextuales (como override o final ).

Por otro lado, en lugares donde previamente se permitía cualquier identificador, agregar una palabra clave representa un riesgo. Por ejemplo:

struct H { my_type f; enum { g }; }; : el uso de la enum class lugar de una nueva palabra clave se debe a que cualquier palabra nueva podría tomarse erróneamente como el inicio de una declaración de miembro de datos en este contexto; solo una palabra clave no es ambigua (en LL (1)), e introducir una nueva podría romper el código.
void h() { my_type f; auto x = g(); } void h() { my_type f; auto x = g(); } : el uso de auto lugar de una nueva palabra clave se debe a que cualquier palabra nueva podría entrar en conflicto con un tipo existente. Todavía es una elección sorprendente, ya que ya era una palabra clave utilizable en esta posición en C (por defecto al tipo int ) pero su significado se modificó (la justificación fue la baja probabilidad de su uso).

Como algunos han mencionado, los idiomas se pueden diseñar sin palabras clave por completo (Haskell se acerca bastante), o se pueden hacer de una manera que las palabras clave se puedan introducir sin problemas (por ejemplo, si cada declaración ya comienza con una palabra clave, entonces la introducción de una nueva palabra clave no puede entrar en conflicto ) Ocurre que C y C ++ no se hicieron así, y de hecho muchos lenguajes tipo C.

Algunos idiomas antiguos no tenían palabras clave en absoluto, en particular PL/1 donde

IF IF=THEN THEN BEGIN; /* some more code */ END;

era un código legal, pero completamente ilegible. (Mire también APL como un ejemplo de lenguaje de programación de escritura principalmente , que es completamente críptico para leer unos meses después, incluso por el autor original del código).

La familia de lenguajes C y C ++ tiene un conjunto de palabras clave definidas por la especificación del lenguaje. Pero hay idiomas muy utilizados con miles de millones de líneas de código fuente heredadas. Si usted (o su comité de estandarización) agrega una nueva palabra clave, existe la posibilidad de colisiones con algún programa existente, y como lo adivinó y otros respondieron, esto es malo. Entonces, si el estándar agregó, por ejemplo, enum_class como una nueva palabra clave, es probable que alguien ya lo haya usado como identificador, y esa entidad no estaría contenta (tener que cambiar su código al adoptar un nuevo estándar C ++).

También se sabe que C ++ se analiza lentamente (en particular, porque los encabezados estándar como <vector> están extrayendo docenas de miles de líneas de código fuente, y porque los módulos aún no están en C ++, y porque la sintaxis es muy ambigua), por lo que es muy compleja el analizador para manejar la nueva sintaxis no es gran cosa (analizar C ++ siempre ha sido horrible de todos modos). Por ejemplo, la comunidad GCC está trabajando mucho más en nuevas optimizaciones que en nuevas características de C ++ (aparentemente, las características recientes de la biblioteca estándar de C ++ requieren mucho trabajo que analizar la nueva sintaxis), incluso si se pasa de C ++ 03 a C ++ 11 fue un gran salto y requirió mucho trabajo en la interfaz de C ++. Esto es menos cierto para el salto de C ++ 11 a C ++ 14.

Algunos otros lenguajes (por ejemplo, algunos dialectos de Lisp, como Common Lisp y algún Scheme , en los que podría redefinir un let o if macro, y las macros en homoiconic como estos son muy diferentes, ya que operan en AST s, desde el mechanism sustitución textual en bruto en C o C ++ ...) permite la redefinición de palabras clave existentes; lea también sobre macros higiénicas . Pero esto puede dificultar la comprensión del código fuente unos meses después.

Creo que es principalmente porque agregar palabras clave romperá el código existente que utiliza esta palabra clave en otros contextos, como sugiere.

Entusiasmo equivocado de "menos es más". Se cree (incorrectamente) que al usar menos palabras clave, los programadores tendrían que aprender menos y ser más productivos antes. Pero esto solo crea confusión sobre la sintaxis.

"Los programadores de Real Perl prefieren que las cosas sean visualmente distintas". ---- Larry Wall

En otras palabras, use una palabra clave solo para una tarea.