El otro día hubo una reunión del comité internacional de normalización C ++ en la ciudad estadounidense de Kona. ¡No fue solo una reunión, sino una función congelada! Ya no pueden filtrarse nuevas ideas serias en el estándar, solo quedan un par de reuniones para agregar cosas preaprobadas, corregir deficiencias y eliminar las asperezas.
Si se esperan módulos y corutinas en C ++ 20, habrá una biblioteca rápida para formatear la salida, podrá trabajar con calendarios, agregarán
std :: stacktrace , el compilador comenzará a llamar
std :: moverse en algunos casos, aceptarán
std :: flat_map ? Todo esto y mucho más te espera bajo el corte.
Coroutines TS
El debate más candente estalló en torno a las corutinas. El comité tuvo que considerar tres enfoques diferentes para las corutinas y decidir si aceptar el Coroutines TS existente como un estándar, o tomar un camino diferente.
La elección no fue fácil, cada enfoque tiene sus desventajas y ventajas:
- N4775 :
- + no hay restricciones sobre el hecho de que las corutinas deben describirse en el archivo de encabezado
- - no hay garantías estrictas de que no habrá asignación dinámica
- ± no es la interfaz más fácil ( P1477R0 corrige esto)
- - palabras clave feas co_await y co_yield (la oración P1485R0 de WP21 corrige esto)
- + 3 años aplicados en la práctica
- P1063R2 :
- + sin asignaciones dinámicas
- - las corutinas deben describirse en el archivo de encabezado o debe engañarse usted mismo con el tipo de borrado
- - aún más operadores clave de miedo [<-] y [->]
- - no hay prototipo de trabajo
- - no es la interfaz más fácil para crear cosas asincrónicas
- P1430R0 :
- + sin asignaciones dinámicas
- - las corutinas deben describirse en el archivo de encabezado o debe salir astutamente con el tipo de borrado usted mismo
- + palabras clave sin miedo, todo es sencillo
- + Los usuarios de Corutin no ven el interior de la rutina de miedo (ni siquiera ven análogos co_await, todo funciona de la caja)
- - la primera propuesta, nunca se ha discutido, requiere muchas mejoras
- - es imposible implementar en las tecnologías actuales (requiere soporte para estructuras de tamaño dinámico), requiere enormes costos laborales para implementar
- ± un poco como fideos de devolución de llamada
Después de mucho debate, las corutinas se adoptaron en C ++ 20 como en Coroutines TS (con prefijos
co_ * y puntos de personalización antiguos).
Módulos
La discusión de los módulos estuvo influenciada por un documento interesante con mediciones de rendimiento:
P1441R0 . Los resultados se pueden interpretar de diferentes maneras: desde "los sistemas de ensamblaje existentes y la implementación de módulos aún no están lo suficientemente optimizados" hasta "los módulos no se adaptan bien con el aumento de la complejidad del proyecto".
Además de este documento, el comité discutió una serie de cambios menores en los módulos actuales. Como resultado, después de 15 años de discusión, creación de prototipos y experimentación con implementaciones, los módulos se adoptaron en C ++ 20.
Formato
¡Buenas noticias a todos! Si no encuentra fallas fatales en el subgrupo Biblioteca, entonces en C ++ 20 será posible formatear cadenas de forma segura y muy rápida. ¡Diga adiós a
std :: ios ,
std :: locale y los otros horrores de los 90! Python ahora tiene una sintaxis similar para formatear fuera de la caja en C ++:
P0645R5 .
Además,
se aceptó la propuesta de integrar el nuevo formato y tiempos de calendario
P1361R0 . Si todo va de acuerdo al plan, entonces las fechas se pueden mostrar de manera humana.
Redes, ejecutores y propiedades
Los ejecutores son un ladrillo importante para admitir Networking en C ++ fuera de la caja. Los ejecutores necesitan propiedades: la capacidad de modificar el tipo de datos, dependiendo del parámetro pasado en la etapa de compilación, sin cambiar el concepto del tipo.
Las propiedades se describen en
P1393R0 . A pesar de que el texto para incluir en el estándar es solo un par de páginas, la propuesta provocó acaloradas discusiones. La propuesta le permite hacer puntos de personalización casi omnipotentes, cambiar el comportamiento de cualquier función usando Propiedades.
Como resultado, se decidió incluir Propiedades en el lenguaje solo en C ++ 23 y, en consecuencia, los Ejecutores y las Redes en C ++ 20 no aparecerán.
Otros
Ya se han realizado los siguientes cambios en el borrador de C ++ 20:
- Las estructuras sin constructores (agregados) ahora se pueden inicializar utilizando paréntesis P0960 . En la práctica, esto significa que ahora std :: make_shared , std :: make_unique , std :: * :: emplace * funcionará correctamente con agregados sin errores de compilación
- Se han agregado funciones Lerp para interpolación lineal P0811
- Se agregó la capacidad de vectorizar los algoritmos de la biblioteca estándar P1001
- Los métodos std :: span ahora devuelven tipos sin signo (similar a la biblioteca estándar completa) + se agregó la función std :: ssize para obtener el tamaño del contenedor como un número con signo P1227
- Los contenedores desordenados aprendieron a buscar valores utilizando un hash precalculado de P0920
Muchas otras cosas esperan la revisión final en los subgrupos Biblioteca y Núcleo para su inclusión en C ++ 20:
- Espera efectiva en std :: atomic; semáforo y clases de barrera P1135
- std :: flat_map P0429
- std :: flat_set P1222
- std :: function_ref P0792
- constexpr para <cmath> y < cstdlib > P0533
- std :: range :: to <any-container> para almacenar un rango de valores en un contenedor P1206
- La capacidad de extraer cadenas de manera eficiente de std :: * stringstream y transferir cadenas personalizadas P0408
- Ediciones múltiples para el operador <=> , rangos, constexpr
Méritos de RG21
El primer día, el subgrupo Core asumió la muy querida propuesta Yandex.Taxi para el
Stacktrace P0881R3 . Los comentarios de diseño se discutieron más a fondo en el subgrupo LEWG, una vez más se resolvió en Core. Como resultado, se hicieron correcciones durante toda la semana y se llevaron a cabo discusiones. La propuesta aún no está incluida en el borrador del estándar, pero debería estar en C ++ 20 (si de repente encuentran algún defecto fatal).
Antes de discutir nuestra idea de
P1485R0 para traer palabras clave para la rutina, no llegó a una conclusión.
También en SG1, Concurrency discutió la idea de un mapa concurrente no ordenado
P0652R2 . Se nos solicitó que verifiquemos nuevamente que la API propuesta evite la contención del lector. También dijeron que investiguen contenedores concurrentes no ordenados que no tienen la función de borrado y no protegen el valor del contenedor de modificaciones competitivas.
La propuesta de
ZaMaZaN4iK para especializar std :: hash para varias clases de la biblioteca estándar
P1406R0 se decidió cortar severamente. El comité recomendó dejar las especializaciones solo para
std :: pair ,
std :: tuple ,
std :: array y
std :: basic_string de los asignadores de usuarios.
En un subconjunto de números, SG6 discutió un mecanismo para la interacción de varias clases nuevas de números
P0880R2 . La propuesta le permite especializar dos plantillas, obtener un conjunto completo de operaciones matemáticas y comparaciones para todos los tipos nuevos. Después de la discusión, decidieron intentar expandir el mecanismo para que pudiera usarse no solo para las necesidades de la biblioteca estándar, sino que también los usuarios podrían usar estos operadores para sus tipos.
También discutimos nuestras sugerencias menores, incluida la macro de prueba de características
P1424R0 y las políticas para agregarlas al estándar.
Discutimos rápidamente nuestra idea de permitir que el compilador elimine copias innecesarias de
R0889R1 . Nos dijeron que continuáramos trabajando en esta dirección y arrojamos ejemplos que no deberían romper con las nuevas reglas.
En lugar de totales
C ++ 20 será tan dramáticamente diferente de C ++ 17 como C ++ 11 será diferente de C ++ 03. Un gran número de nuevas tecnologías y nuevos paradigmas: conceptos, contratos, rangos, módulos, corutinas, contenedores constexpr y polimorfismo dinámico constexpr, "nibloides", etc.
Pronto
, nosotros, el Grupo de Trabajo 21, publicaremos comentarios sobre un borrador del estándar C ++ 20. Por lo tanto, si tiene algún dolor o no está de acuerdo con ninguna innovación, deje sus pensamientos
en esta página .
La próxima reunión del comité internacional será en el verano, en la cual las innovaciones para C ++ 23 pueden comenzar a considerarse. Si desea cambiar algo en C ++ o proponer su idea, siempre puede escribir en
https://stdcpp.ru/ , donde la gente de WP21 lo ayudará a transmitir sus deseos al comité.
¿Te gustaría hablar con nosotros en vivo? Una reunión abierta de RG21 se llevará a cabo pronto, esté
atento a los anuncios en events.yandex.ru . También búsquenos en la conferencia de abril
C ++ Rusia en Moscú.