Preguntas frecuentes preliminares: ¿Por qué los estándares C ++ salen cada tres años?

WG21 tiene un calendario estricto (ver P1000 ) para el lanzamiento estándar cada tres años. Y sin demoras.

Durante cada ciclo, recibimos regularmente preguntas "¿Por qué es tan estricto?", Especialmente de los nuevos miembros del comité que no están familiarizados con su historia y las razones del estado actual de las cosas. Y durante una teleconferencia preliminar con la administración de Colonia, varias personas recomendaron describir por qué estábamos haciendo esto y cómo se tomó la decisión de adoptar este horario.

Pinté todo esto en forma de preguntas y respuestas para el próximo borrador de P1000, y envié una copia a los miembros del comité camino a Colonia. Este material se publicará en la próxima versión pública de P1000, lo enviaremos en unas pocas semanas a partir del momento actual.

Sin embargo, el borrador de preguntas frecuentes puede ser de interés para el público, por lo que le ofrezco una copia. Espero que en su mayor parte le sea útil, iluminarse de alguna manera y tal vez incluso entretener un poco.

Hay errores en el estándar, ¿debería posponer C ++ 20?

Por supuesto que si y no.

Nos estamos moviendo en una dirección determinada a una velocidad elegida: las correcciones de errores están planificadas para este último año, por lo que el programa a principios de C ++ "19" (Kona) establece una fecha límite para detener la adición de características en C ++ "20" para que tuvimos un año para corregir errores, incluido trabajar con comentarios de diferentes países este verano. Antes del comienzo de 2020 (reuniones en Colonia, Belfast y Praga), debemos dar retroalimentación y aplicar cualquier otra solución a los problemas, así como la corrección de errores.

Si tenemos una o dos reuniones más, entonces podríamos agregar un <nombre de la función>, que está casi listo, ¿debería posponer C ++ 20?

Por supuesto que si y no.

Espere a que se celebren un par de reuniones más (después de Praga), y C ++ 23 estará abierto para los negocios, y en primer lugar votaremos para agregar <nombre de la característica> al borrador de trabajo de C ++ 23. Esto es lo que hicimos con los conceptos: no estaban listos para la transición de TS directamente a C ++ 17. Por lo tanto, en la primera reunión sobre C ++ 20 (en Toronto), votaron para transferir la funcionalidad básica de los conceptos al borrador de C ++ 20, que dio mucho tiempo para mejorar y refinar el resto de la parte contradictoria de la sintaxis TS (no "plantilla"), que se introdujo el año que viene (San Diego). Ahora toda la funcionalidad está lista.

Esto parece ser demasiado estricto. ¿Por qué publicar versiones IS a intervalos fijos (tres años)?

Porque en el caso del lanzamiento de C ++ IS, esta es una de las dos opciones principales para la gestión de proyectos, y la experiencia muestra que esta opción es mejor que la segunda.

¿Cuáles son las dos opciones para la gestión de proyectos para el lanzamiento de C ++ IS?

Me alegra que hayas preguntado.

En el caso de un lanzamiento, hay dos opciones principales: elegir una función o una fecha de lanzamiento, y cuando selecciona una, pierde el control sobre la definición de la otra. No puedes controlar simultáneamente ambos. En resumen:


Yo explico:

(1) "Qué": seleccionamos características y enviamos como listas, no es necesario elegir un tiempo de lanzamiento . Si resulta que necesita más tiempo para finalizar una característica del borrador del estándar, entonces todo el mundo tendrá que esperar por usted. Trabaja en grandes funciones que requieren varios años de desarrollo, y luego intenta dejar de trabajar en nuevas funciones mientras estabiliza el lanzamiento.

Así fue con C ++ 98 (se esperaba alrededor de 1994, Björn dijo que si el lanzamiento no salía para entonces sería un fracaso) con C ++ 11 (se llamó 0x porque se esperaba x para 2007 ) Este es un enfoque de "dejar al paciente sin blindaje" durante un período indefinido, lo que condujo a un retraso en las pruebas de integración y liberación. Y esto, a su vez, condujo a una gran incertidumbre en el mercado con respecto al momento del próximo estándar y si se lanzará (sí, no solo los participantes en el desarrollo, sino incluso algunos miembros del comité dudaron seriamente en 1996 y 2009). ¿hay lanzamientos relevantes)? Durante varios años, la mayoría de los compiladores no cumplieron con el estándar, porque nadie sabía cuántos cambios incompatibles implementaría el comité en la nueva versión, o cuándo se esperaría. Esto ha llevado a una gran variedad y fragmentación del soporte de C ++ en compiladores disponibles para la comunidad.

¿Por qué hicimos esto, somos idiotas? En realidad no, simplemente eran inexpertos y ... digamos, "optimistas". Era un camino pavimentado con las mejores intenciones. En 1994-1996 y en 2007-2009 realmente creímos que ahora moveríamos otra, dos o tres reuniones, y haríamos todo, y cada vez se pospondrían hasta cuatro años. Y ahora han visto por su propia experiencia que no puede haber transferencia por un año o dos.

Afortunadamente, todo ha cambiado gracias a la opción (2).

(2) “Cuándo”: seleccionamos la fecha de lanzamiento y enviamos las funciones que están listas, no necesita seleccionar un conjunto de funciones . Si resulta que se necesita más tiempo para refinar una característica de un borrador de estándar, la descartamos y enviamos lo que está listo. Puede continuar trabajando en funciones grandes, cuya creación lleva tiempo como para varios lanzamientos, pero hágalo en "sucursales" de terceros, agregándolas a la rama maestra IS tan pronto como esté listo. Y trabajas constantemente en funciones, porque su desarrollo está completamente separado de la versión actual (no hay un gran punto de conexión).

Nos hemos adherido a este enfoque desde 2012 y no queremos abandonarlo. Este es el enfoque de "parchear regularmente al paciente", que lleva a la expectativa de una mayor calidad debido a integraciones regulares forzadas y la negativa a agregar trabajo al borrador IS hasta que alcance un cierto nivel de estabilidad, generalmente dentro de la rama característica. También crea un ciclo de lanzamiento predecible en el que el mercado puede confiar. Con los años, los autores de compiladores comenzaron cada vez más temprano, después del próximo lanzamiento, a lanzar versiones de sus productos que se ajustaban al estándar, lo cual nunca antes había sucedido. Y en 2020, esperamos el lanzamiento de implementaciones totalmente compatibles en un año con el lanzamiento del estándar, que nunca antes había sucedido. Esto es solo para el beneficio de todo el mercado: desarrolladores, usuarios, maestros.

Y también tenga en cuenta que desde que comenzamos a adherirnos a este enfoque, hemos comenzado a hacer más (si se mide por características grandes, medianas y pequeñas) y con mayor calidad (si se mide por una reducción estricta en el número de informes de errores y comentarios sobre borradores de cada estándar). Aunque enviamos lo que logramos preparar (y si no logramos algo, no lo enviamos).

¿Qué tan serio eres sobre el enfoque (2)? Si, según un miembro autorizado del comité, alguna característica importante está "casi lista", entonces estarás tentado a esperar un poco, ¿verdad?

Muy en serio, y no.

Tenemos estadísticas: en 2016 en Jacksonville, cuando finalmente decidimos las características de C ++ 17, Björn Straustrup habló en una reunión plenaria con una propuesta para incluir conceptos en C ++ 17. Cuando no se llegó a un consenso, se le preguntó directamente a Straustrup si quería retrasar el lanzamiento de C ++ 17 durante un año para incluir conceptos en él. Björn respondió "no" sin dudarlo y evadirlo, y agregó que C ++ 17 sin conceptos era más importante que C ++ 18 o C ++ 19 con conceptos, aunque Straustrup había estado trabajando en ellos durante unos 15 años. La elección fue esta: (2) lanzamos C ++ 17 sin conceptos, y luego C ++ 20 con conceptos (lo que hicimos), o (1) cambiamos el nombre de C ++ 17 a C ++ 20, que es isomorfo (2) con la excepción de omitir C ++ 17 y negarse a lanzar lo que ya estaba listo para C ++ 17.

¿Qué pasa con la compensación entre (1) y (2)? Digamos, generalmente nos adherimos a (2), pero con "poca" flexibilidad en términos de obtener "un poco" de tiempo extra, si necesita refinar la función.

No, porque resulta (1).

Fred Brooks en The Mythical Man-Month popularmente explicó "la pequeña transferencia mítica" y concluyó: " No permita ninguna transferencia pequeña ".

Imagina que portamos C ++ 20. Tendríamos que regresar de (2) a (1), sin importar cuánto nos esforcemos por evitarlo, y al mismo tiempo no recibiríamos ningún beneficio. Si decidiéramos posponer C ++ 20 para pulirlo, retrasaríamos el estándar por al menos dos años. No existen conceptos tales como la transferencia de una o tres reuniones, porque durante este tiempo otros continuarán (de manera justa) para decir: "Bueno, mi función solo necesita una reunión más, todavía la reprogramamos, transfiramos otra". Y si transferimos al menos dos años, significa que C ++ 20 se convierte en C ++ 22, y muy probablemente C ++ 23 ... ¡pero ya vamos a enviar C ++ 23! - Es decir, en cualquier caso, enviaremos C ++ 23, y la única diferencia es que no transferimos C ++ 20 con una gran cantidad de trabajo realizado, listo para su lanzamiento, y no hacemos que el mundo entero espere otros tres años. La demora no beneficiará estas características, la mayoría de ellas o todas juntas.

Por lo tanto, la oración es equivalente a "convirtamos C ++ 20 en C ++ 22 o C ++ 23", y la respuesta simple es: "sí, tendremos C ++ 23, pero además de C ++ 20, y no en su lugar ". Un retraso de C ++ 20 significa omitir C ++ 20 en lugar de lanzar un producto terminado bueno y estable, y esto no tendrá ningún beneficio.

¡Pero la función X está rota / lleva más tiempo del que nos queda para corregir errores en C ++ 20!

No hay duda! Solo podemos cortarlo.

En este caso, alguien tendrá que escribir una carta en EWG o LEWG (dependiendo de la situación) con una descripción de la situación, y ofrecer eliminar la función del borrador de trabajo IS. Estos grupos considerarán la apelación, y si deciden que la función está rota (y el pleno está de acuerdo con ellos), la función se pospondrá hasta la próxima versión de C ++. Ya hicimos esto con los conceptos de C ++ 0x.

Pero en el caso de (1), transferiremos no solo esta función, sino todo el conjunto de funciones de C ++ 20 a C ++ 23. Eso sería ... busto.

¿El enfoque (2) significa lanzamientos "mayores / menores"?

No Al principio dijimos esto hasta que nos dimos cuenta de que (2) solo significa que no es necesario elegir un conjunto de características incluso desde el punto de vista de la versión "principal / secundaria".

Enfoque (2) significa solo "enviamos lo que está listo". Se obtienen lanzamientos:

• el mismo tamaño (es decir, generalmente promedio) para las características es "más pequeño" porque se dedica menos tiempo a su desarrollo (por ejemplo, menos de tres años cada una), y en general obtenemos la misma cantidad de características completadas en el lanzamiento;
  
• y un tamaño variable (no es necesario una o dos veces) para las funciones "más grandes", que toman más tiempo (por ejemplo, más de tres años cada una), y cada versión de IS incluye tantas de estas características como logran completar para su lanzamiento. Por lo tanto, en algunos lanzamientos hay más, en otros menos.
  

C ++ 14 y C ++ 17 eran relativamente pequeños, porque se invirtió mucho esfuerzo en la estandarización de las funciones de larga duración descritas en las propuestas de implementación (por ejemplo, contratos) y "ramas de características" en TS (por ejemplo, conceptos).

C ++ 20 es un gran lanzamiento ...

Si C ++ 20 tiene muchas características principales. Tres de los más grandes comienzan con "ko" (conceptos, contratos, corutinas), por lo que podríamos llamarlo co_cpp20. O codependiente.

... y no se hace demasiado en el ciclo de tres años para C ++ 20?

No, ver arriba "una vez a la vez no es necesario".

C ++ 20 es importante no porque hayamos hecho más en tres años, sino porque hay muchos desarrollos largos (incluyendo al menos dos en los que hemos estado trabajando en la forma actual desde 2012 en forma de oraciones P y ramas TS ) llegaron a la fase de preparación y decidieron incluirlos en el borrador IS de la misma versión.

Casi siempre, las características principales se desarrollan durante muchos años. La principal diferencia entre el enfoque (1) para C ++ 98 y C ++ 11 y el enfoque (2) es que en C ++ 98 y C ++ 11 el lanzamiento se retrasó hasta que todas estas características estuvieron listas, y ahora enviamos grandes tan pronto como esté listo, y junto con ellos lanzaremos mucho más.

C ++ 20 pasó por el mismo ciclo de tres años que C ++ 14 y C ++ 17. No hemos hecho más en los últimos tres años que en los dos ciclos anteriores, solo agregamos más a las características principales. Si alguno de ellos no estuviera listo, lo habríamos tirado y terminado para C ++ 23. Si esto sucede, informaremos esto en la propuesta de implementación y explicaremos los motivos.

C ++ 14 + 17 + 20 conformaron nuestro tercer ciclo de nueve años (2011-2020) después de C ++ 98 (1989-1998) y C ++ 11 (2002-2011). Pero como nos adherimos al enfoque (2), también lanzamos desarrollos que estaban listos para el final de los ciclos de tres y seis años.

¿No es mejor detectar errores cuando un producto está en desarrollo y no después de su lanzamiento?

Por supuesto que es mejor.

Pero si hablamos de las razones de la demora en el lanzamiento del estándar C ++, entonces esta pregunta implica dos suposiciones falsas:

• que antes de que se lanzara el estándar, las características no aparecían y no se usaban (para muchos, ya existe experiencia en producción);
  
• y que todas las funciones se pueden usar juntas hasta que se libere el estándar (no permitido).
  

Yo explico:

1. La mayoría de las características principales de C ++ 20 se implementaron en la forma en que se reflejan en el borrador actual del estándar en al menos un compilador, y en la mayoría de los casos ya se han utilizado en el código de producción (es decir, ya están disponibles para usuarios que están muy satisfechos) . Por ejemplo, las corutinas (introducidas solo cinco meses antes de este artículo) se usaron durante dos años en producción en MSVC y un año en Clang, lo que estaba muy satisfecho con los grandes clientes (por ejemplo, Azure y Facebook).
2. No vamos a detectar muchos problemas de interacción entre las características hasta que los usuarios comiencen a usarlas en la producción, es decir, antes de que se lance el estándar, porque muchos desarrolladores esperarán a que se lance para implementar diferentes proyectos. Y si mostramos incertidumbre sobre el momento del lanzamiento, estas implementaciones también se retrasarán. Bueno, todavía implementan algo, pero se detendrá mucho hasta que los desarrolladores estén seguros de que estamos listos para lanzar. Pregunte a los creadores de <nombre del compilador favorito> qué sucedió cuando implementaron <nombre de la función grande> antes de que apareciera en el estándar publicado. En muchos casos, es necesario implementarlo repetidamente y separar a los consumidores repetidamente. Por lo tanto, los desarrolladores prefieren esperar a que el comité apruebe ciertas características.

Finalmente, no te olvides del problema de las características de interacción. No solo los lanzamos cuando estamos listos, después de eso todavía necesitamos tiempo para buscar problemas de interacción entre características y agregar soporte para tales interacciones, que simplemente no podemos descubrir antes de que las nuevas características se utilicen ampliamente. Y no importa cuánto demoremos el lanzamiento del estándar, siempre habrá interacciones que podremos explorar solo mucho más tarde. Debe gestionar este riesgo con la ayuda de un diseño flexible, asegurando la compatibilidad de las funciones, y no esperar a deshacerse de todos los riesgos.

El estándar nunca será perfecto ... ¿no liberan errores?

Si

Si vemos que la función no está lista, debemos eliminarla de la versión.

Si vemos que una función puede ser mejor, y sabemos que el cambio puede ser compatible con versiones anteriores, entonces esta no es una razón para rechazar su lanzamiento ahora. Se puede lanzar como una extensión en el siguiente C ++.

Lanzamos intencionalmente funciones que planeamos mejorar en el futuro, mientras confiamos en que podemos mantener la compatibilidad con versiones anteriores.

¿Pero no deberías tratar de minimizar los errores de lanzamiento?

Si Estamos intentando

Pero no intentamos evitar todos los riesgos. También existe el riesgo y (posible) precio de negarse a liberar lo que nos parece listo. Y la mayoría de las veces, tenemos razón.

¿Estás seguro de que ahora la calidad es mejor que usar el enfoque (1)?

Si

Según las métricas objetivas, el volumen de comentarios de diferentes países y los informes de errores, C ++ 14 y C ++ 17 fueron nuestras versiones más estables, y según estas métricas fueron 3-4 veces más altas que C ++ 98 y C ++ 11. Y la razón está precisamente en la regularidad de los lanzamientos, en colocar las características grandes primero en las ramas TS (incluidas las descripciones completas de su integración con el estándar principal) y en su posterior infusión, cuando estamos convencidos de que estamos listos.

Desde 2012, el estándar principal siempre se ha mantenido en un estado casi listo para su envío (de modo que incluso los borradores de trabajo son de la misma alta calidad que los lanzamientos de los estándares C ++ 98 y C ++ 11). Esto nunca ha sucedido antes, cuando mantuvimos al paciente sin seguridad durante mucho tiempo, con largas listas de problemas y órganos repartidos, que vamos a volver a colocar pronto. Ahora sabemos que podemos mantener un cronograma con un trabajo de alta calidad, porque siempre permanecemos en un estado de preparación cercana para el lanzamiento. Si lo desea, podría lanzar un CD incluso ahora, sin reunirse en Colonia, y aún así la calidad sería mucho más alta que nunca con un CD C ++ 98 o C ++ 11 (en verdad, y sus estándares publicados) . Y teniendo en cuenta que C ++ 98 y C ++ 11 tuvieron éxito, la comprensión de que ahora la calidad es aún mayor significa que estamos en el camino correcto.

C ++ 98 y C ++ 11 se desarrollaron durante aproximadamente 9 años y fueron muy buenos productos ...

Sí: 1989-1998 y 2002-2011.

... y C ++ 14 y C ++ 17 fueron lanzamientos menores. ¿Es C ++ 20 una versión importante?

Repito, creo que es correcto comparar C ++ 14 + 17 + 20 en su conjunto: este es nuestro ciclo de nueve años, pero como nos adherimos al enfoque (2), también lanzamos los desarrollos que estaban listos para completar los ciclos de tres y seis años. .

¿El enfoque (2) le permite alcanzar objetivos basados ​​en funciones como P0592 para el próximo C ++?

Por supuesto! Si bien no contiene palabras como "debería incluir estas características", porque entonces será el enfoque (1).

Es normal luchar por un cierto conjunto de características y darle prioridad a una de ellas, pero luego es una cuestión de prioridad. Hasta ahora, solo tomaremos lo que está listo, pero podemos elegir en qué trabajar primero para prepararnos lo antes posible.