¿Por qué el Estándar C ++ no adoptó plantillas de expresión?


17

Tengo entendido que las plantillas de expresión como técnica se descubrieron significativamente antes del estándar C ++ original en 1998. ¿Por qué no se utilizaron para mejorar el rendimiento de varias clases estándar como std::stringy streams?


@ChrisLively: Si tuviera que presentar una propuesta que sugiriera tal cambio, entonces sería absolutamente un problema que no supiera por qué no se hizo la primera vez, y es absolutamente relevante para la programación y la respuesta es muy específico.
DeadMG

¿Qué harías exactamente con las plantillas de expresión para acelerar las cadenas?
jalf

55
@jalf: si lo aplicara operator+, podría lograr O(n)y cero asignaciones redundantes para asignaciones repetidas, algo que aún es más rápido que las referencias de valor. Además, podría optimizar, por ejemplo, las implementaciones de COW copiando en escritura , no solo "en índice en no constante". También hay otras aplicaciones en las que tanto el rendimiento como la semántica se pueden mejorar con plantillas de expresión.
DeadMG

Me di cuenta de que esta pregunta se hizo hace un tiempo, pero por favor elabore algunos sobre qué son las plantillas de expresión y / o enlace a material relevante.
einpoklum

Respuestas:


17

Las plantillas de expresión fueron publicadas por primera vez por Todd Veldhuizen en junio de 1995 , en un artículo en el Informe C ++ revista . En ese momento, el comité estándar ya estaba muy involucrado en agregar el STL al estándar C ++, una tarea que por sí sola retrasó el estándar en uno o dos años. (El STL se presentó al comité en 1993 y se propuso oficialmente en 1994. Tomó otros cuatro años terminar el estándar).
Dado que el comité de estandarización de C ++ es un grupo de voluntarios, algunos de ellos ni siquiera respaldados por compañías que pagan gastos, no creo que nadie tuviera recursos para agregar otra idea al estándar C ++.

Además, 1995 es solo el año en que se publicó el artículo de Veldhuizen. Para que la técnica sea conocida y reconocida , tendría otros años . (La idea del STL se remonta a los años 70, una implementación de Ada se realizó a fines de los 80, el trabajo en una implementación de C ++ debe haber comenzado alrededor de 1990, y la idea tardó otros tres años en encontrar la forma de estandarización de C ++ comité.)
Hubo, sin embargo, solo tres años desde el artículo de Todd hasta la votación final sobre el estándar. Ese fue muy poco tiempo para incorporar una idea que todavía era nueva y básicamente no había sido probada.

Agregue a eso el hecho de que las Plantillas de expresión , al ser una especie de metaprogramación de plantillas, estresan mucho más a los compiladores que el STL comparativamente "simple". Y por lo que recuerdo, incluso en 1998, cuando se publicó el estándar, no teníamos un compilador que incluso pudiera compilar todo el STL.
Dado que uno de los principales objetivos del comité de estandarización era estandarizar la práctica establecida (no es que se apegaran a esto rigurosamente), las Plantillas de Expresión nunca deberían haber estado en la agenda en ese entonces.


1
Pero std::stringy iostreams no estaban en el STL.
R. Martinho Fernandes

@ R.MartinhoFernandes: Sin embargo, eso no significa que el comité tuviera recursos de sobra. (Y std::string fue cambiado para convertirlo en un contenedor STL, por cierto.)
sbi

2
Creo que solo tengo que vincular esto: ¿Es std :: string parte del STL?
Xeo

@sbi ah, eso tiene sentido.
R. Martinho Fernandes

10

La respuesta es simple: que , obviamente, no ejercer presión para él. Tampoco lo hice porque tenía (y tengo) mi propia agenda que no incluye plantillas de expresión. Además, la interfaz en particular para cadenas ya está tratando de servir demasiados maestros, lo que resulta en una clase que se usa para todo y es buena para la polilla.

La biblioteca estándar ya tiene una std::valarrayfamilia que está diseñada para admitir un estilo de implementación de plantilla de expresión. Sin embargo, hasta donde puedo decir, no es suficiente. Un problema que causó esto es que las personas que presionaron para que se incluyera su versión a medias en el estándar dejaron de funcionar en el momento en que se incluyó. Hubo intentos de rescatarlo (por ejemplo, David Vandevoorde, Matt Austern y yo trabajamos en ello durante un día más o menos en la reunión de Estocolmo), pero al final nadie estaba lo suficientemente interesado.


8
Comienzas un poco injusto, porque DeadMG no pudo presionar por ello debido al simple hecho de que apenas había superado los pañales en ese momento y probablemente no había llegado al punto en el que pudiera pronunciar correctamente "C ++". :)
sbi

77
Lamento mucho que cuando era un niño, no recibí presión: P
DeadMG

1
Me doy cuenta de que no todos tuvieron la oportunidad de influir en el estándar. Aunque asisto regularmente a las reuniones del comité desde hace aproximadamente 15 años, mi influencia en el estándar es limitada. Sin embargo, mi punto es: si alguien quiere algo en el estándar, ¡deben hacer un esfuerzo! Las cosas que no están allí se deben esencialmente a que las personas tienen otras prioridades, ya sean técnicas o de otro tipo (por ejemplo, concentrarse por completo en crecer).
Dietmar Kühl

La implementación libgcc de bases valarray en plantillas de expresión.
phresnel

3

La técnica ahora conocida como "plantillas de expresión" fue descubierta (de forma independiente) al menos ya en 1994 por Todd Veldhuizen y por mí (el artículo de Todd es de 1995, pero lleva un poco de tiempo publicar las cosas; mi propio trabajo se mostró por primera vez en comp.lang.c ++).

De hecho, comencé a asistir a las reuniones del comité de C ++ exactamente por este problema. Presenté la técnica y un rediseño completo de std :: valarray al comité en la primera reunión de Santa Cruz en marzo de 1996. Se consideró un cambio demasiado grande, pero como alude Dietmar, recibimos algunas palabras en la reunión posterior. en Estocolmo que permiten el uso de plantillas de expresión para la implementación de std :: valarrray. Para mi sorpresa, esas palabras todavía están ahí: vea el párrafo 3-6 de la subsección [valarray.syn] 29.7.1 en http://wg21.link/N4727 .


1
me pregunto cuál es el punto de usar acortador de enlaces en lugar de la URL real
mosquito

3
@gnat: Si conoce un número de documento, es trivial escribir la URL wg21.link para él. Eso es lo que hice aquí. Me ahorra buscar el correo / año en particular en el que se publicó un documento. Además, espero que si / cuando WG21 decida mover las URL de alojamiento, wg21.link se actualizará en consecuencia, evitando así las referencias obsoletas. (Es decir, el punto no es acortar, sino legibilidad.)
Daveed V.

0

Mi mejor conjetura es que ningún compilador habría podido compilar plantillas de expresión en 1998.


1
Todd Veldhuizen hizo su trabajo de plantilla de expresión antes de 1996 usando el compilador C ++ de KAI. La razón es mucho más profana ...

1
Un gran porcentaje de la comunidad de C ++ no pudo usar el STL en todo su potencial hasta 2003 tampoco (¡lo estoy mirando, Microsoft!), Y eso no detuvo al comité para incorporar el STL en el estándar.
sbi

2
En realidad, bth Todd y yo originalmente obtuvimos la técnica de plantillas de expresión para trabajar en el compilador Borland C ++ 4 (que se lanzó en 1993). Por cierto, creo que ese es también el primer compilador en el que se hizo que el STL funcionara por completo. Más tarde porté una biblioteca de plantillas de expresión a una variedad de otros compiladores (¡incluido el compilador basado en Sun's Cfront en ese momento!). La cámara del compilador KAI C ++ un poco más tarde.
Daveed V.

@DaveedV. ¡BCC4 fue un compilador muy bueno para su época y mucho mejor que la versión VC de esa época! Sin embargo, tenía algunas peculiaridades, como el infame "smiley bug". :->Además, no pudieron mejorarlo lo suficientemente rápido, por lo que rápidamente se hizo cada vez más difícil usar las técnicas de plantillas que mejoran rápidamente con él. Cuando se lanzó VC7.1 y cumplió mucho más, eso mató a Borland.
sbi
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.