Projet de FAQ: Pourquoi les normes C ++ sont-elles publiées tous les trois ans?

Le WG21 a un calendrier strict (voir P1000 ) pour une sortie standard tous les trois ans. Et pas de retards.

Au cours de chaque cycle, nous recevons régulièrement des questions «Pourquoi est-ce si strict?», En particulier de nouveaux membres du comité qui ne connaissent pas son histoire et les raisons de l'état actuel des choses. Et lors d'une téléconférence préliminaire avec l'administration de Cologne, plusieurs personnes ont recommandé de décrire pourquoi nous faisions cela et comment la décision a été prise d'adopter ce calendrier.

J'ai peint tout cela sous forme de questions et réponses pour le prochain projet de P1000 et j'en ai envoyé une copie aux membres du comité en route pour Cologne. Ce matériel sera publié dans la prochaine version publique de P1000, nous vous l'enverrons dans quelques semaines à partir du moment actuel.

Cependant, le projet de FAQ peut intéresser le public, je vous en offre donc une copie. J'espère que, pour la plupart, il vous sera utile, vous éclairera à certains égards et peut-être même vous divertira un peu.

Il y a des bogues dans la norme, devriez-vous reporter C ++ 20?

Bien sûr, oui et non.

Nous évoluons dans une direction donnée à une vitesse choisie: des corrections de bogues sont prévues pour cette dernière année, donc le calendrier du début C ++ "19" (Kona) fixe une date limite pour arrêter l'ajout de fonctionnalités (gel des fonctionnalités) en C ++ "20", de sorte que nous avons eu un an pour corriger les bugs, notamment en travaillant avec les commentaires de différents pays cet été. Avant le début de 2020 (réunions à Cologne, Belfast et Prague), nous devons donner un retour et appliquer toute autre solution aux problèmes, ainsi que des corrections de bugs.

Si nous avons une ou deux réunions supplémentaires, nous pourrions ajouter un <nom de fonctionnalité>, qui est presque prêt, alors devriez-vous reporter C ++ 20?

Bien sûr, oui et non.

Attendez quelques réunions supplémentaires (après Prague), et C ++ 23 sera ouvert aux entreprises, et tout d'abord nous voterons pour l'ajout de <fonctionnalité nom> au projet de travail de C ++ 23. C'est ce que nous avons fait avec les concepts: ils n'étaient pas prêts pour la transition de TS directement en C ++ 17. Par conséquent, lors de la première réunion sur C ++ 20 (à Toronto), ils ont voté pour transférer la fonctionnalité de base des concepts au projet C ++ 20, ce qui a donné beaucoup de temps pour améliorer et affiner le reste de la partie contradictoire de TS (syntaxe non «modèle»), qui a été introduite. l'année prochaine (San Diego). Maintenant, toutes les fonctionnalités sont prêtes.

Cela semble trop strict. Pourquoi publier des versions IS à intervalles fixes (trois ans)?

Parce que dans le cas de la sortie de C ++ IS, c'est l'une des deux options principales pour la gestion de projet, et l'expérience montre que cette option est meilleure que la seconde.

Quelles sont les deux options de gestion de projet pour la sortie de C ++ IS?

Heureux que vous ayez demandé.

Dans le cas d'une version, il existe deux options principales: choisir une fonctionnalité ou une date de sortie, et lorsque vous en sélectionnez une, vous perdez le contrôle de la définition de l'autre. Vous ne pouvez pas contrôler simultanément les deux. En bref:


J'explique:

(1) «Quoi»: nous sélectionnons les fonctionnalités et expédions comme prêt, pas besoin de choisir une heure de sortie . S'il s'avère que vous avez besoin de plus de temps pour finaliser une fonctionnalité du projet de norme, alors le monde entier devra vous attendre. Vous travaillez sur de grandes fonctionnalités qui nécessitent plusieurs années de développement, puis vous essayez d'arrêter de travailler sur de nouvelles fonctionnalités tout en stabilisant la version.

Donc c'était avec C ++ 98 (c'était prévu vers 1994, Björn a dit que si la version ne sortait pas alors ce serait un échec) avec C ++ 11 (ça s'appelait 0x parce que x était attendu en 2007 ) Il s'agit d'une approche «laisser le patient sans surveillance» pour une durée indéterminée, ce qui a entraîné un retard dans les tests d'intégration et la libération. Et cela, à son tour, a conduit à une grande incertitude du marché concernant le calendrier de la prochaine norme, et si elle sera publiée (oui, non seulement les participants au développement, mais même certains membres du comité sérieusement doutés en 1996 et 2009, apparaîtront existe-t-il des versions pertinentes). Pendant plusieurs années, la plupart des compilateurs n'ont pas respecté la norme, car personne ne savait combien de changements incompatibles le comité allait déployer dans la nouvelle version, ou quand serait-il attendu du tout? Cela a conduit à une grande variété et à une fragmentation de la prise en charge C ++ dans les compilateurs disponibles pour la communauté.

Pourquoi avons-nous fait cela, sommes-nous des idiots? Pas vraiment, ils étaient juste inexpérimentés et ... disons, "optimistes". C'était une route pavée des meilleures intentions. En 1994-1996 et en 2007-2009, nous pensions vraiment que nous allions maintenant proposer une, deux ou trois réunions de plus, nous ferions tout et chaque fois, elles seraient reportées de quatre ans. Et maintenant, ils ont vu de leur propre expérience qu'il ne peut y avoir de transfert pendant un an ou deux.

Heureusement, tout a changé grâce à l'option (2).

(2) «Quand»: nous sélectionnons la date de sortie et expédions les fonctionnalités qui sont prêtes, vous n'avez pas besoin de sélectionner un ensemble de fonctionnalités . S'il s'avère que plus de temps est nécessaire pour affiner une fonction d'un projet de norme, nous la rejetons et expédions ce qui est prêt. Vous pouvez continuer à travailler sur de grandes fonctionnalités, dont la création prend du temps comme pour plusieurs versions, mais faites-le dans des "branches" tierces, en les ajoutant à la branche maître IS dès que vous le pouvez. Et vous travaillez constamment sur les fonctionnalités, car leur développement est complètement distinct de la version actuelle (il n'y a pas de gros point de connexion).

Nous adhérons à cette démarche depuis 2012 et ne souhaitons pas l'abandonner. Il s'agit de l'approche consistant à «rafistoler régulièrement le patient», ce qui conduit à s'attendre à une qualité supérieure en raison des intégrations régulières forcées et au refus d'ajouter du travail au projet IS jusqu'à ce qu'il atteigne un certain niveau de stabilité, généralement dans la branche des fonctionnalités. Cela crée également un cycle de publication prévisible sur lequel le marché peut compter. Au fil des ans, les auteurs de compilateurs ont commencé de plus en plus tôt, après la prochaine version, à publier des versions de leurs produits conformes à la norme, ce qui n'était jamais arrivé auparavant. Et en 2020, nous attendons la sortie d'implémentations entièrement conformes dans un an avec la sortie de la norme, ce qui n'a jamais eu lieu auparavant. Ce n'est que pour le bénéfice de l'ensemble du marché - développeurs, utilisateurs, enseignants.

Et notez également que depuis que nous avons commencé à adhérer à cette approche, nous avons commencé à en faire plus (si mesuré par des fonctionnalités grandes, moyennes et petites) et avec une qualité supérieure (si mesuré par une réduction stricte du nombre de rapports de bogues et de commentaires sur projets de chaque norme). Bien que nous expédions ce que nous avons réussi à préparer (et si nous n'avons pas réussi quelque chose, nous ne l'expédions pas).

À quel point êtes-vous sérieux au sujet de l'approche (2)? Si, selon un membre faisant autorité du comité, une grande caractéristique est «presque prête», alors vous serez tenté d'attendre un peu, non?

Très sérieusement, et non.

Nous avons des statistiques: en 2016 à Jacksonville, lorsque nous avons finalement décidé des fonctionnalités pour C ++ 17, Björn Straustrup a pris la parole lors d'une réunion plénière avec une proposition d'inclure des concepts dans C ++ 17. Quand aucun consensus n'a été atteint, Straustrup a été directement demandé s'il voulait retarder la sortie de C ++ 17 pendant un an afin d'y inclure des concepts. Björn a répondu «non» sans hésitation et évasion, et a ajouté que C ++ 17 sans concepts était plus important que C ++ 18 ou C ++ 19 avec concepts, bien que Straustrup y travaille depuis environ 15 ans. Le choix était le suivant: (2) nous publions C ++ 17 sans concepts, puis C ++ 20 avec concepts (ce que nous avons fait), ou (1) nous renommons C ++ 17 en C ++ 20, qui est isomorphe (2) à l'exception de sauter C ++ 17 et de refuser de libérer ce qui était déjà prêt pour C ++ 17.

Qu'en est-il du compromis entre (1) et (2)? Disons, nous adhérons généralement à (2), mais avec «peu» de flexibilité pour obtenir «un peu» de temps supplémentaire, si vous avez besoin d'affiner la fonctionnalité?

Non, car il s'avère (1).

Fred Brooks dans The Mythical Man-Month a populairement expliqué "le petit transfert mythique" et a conclu: " Ne permettez pas de petits transferts ."

Imaginez que nous ayons porté C ++ 20. Nous devions revenir de (2) à (1), peu importe à quel point nous essayons de l'éviter, et en même temps, nous ne recevrions aucun avantage. Si nous décidions de reporter le C ++ 20 pour le peaufiner, nous retarderions la norme d'au moins deux ans. Il n'y a pas de concepts tels que le transfert d'une ou trois réunions, car pendant ce temps, d'autres continueront (assez) à dire: "Eh bien, ma fonctionnalité n'a besoin que d'une réunion de plus, nous l'avons toujours reportée, transférons-en une autre." Et si nous transférons au moins deux ans, cela signifie que C ++ 20 devient C ++ 22, et très probablement C ++ 23 ... mais nous allons déjà expédier C ++ 23! - C'est-à-dire, dans tous les cas, nous expédierons C ++ 23, et la seule différence est que nous ne transférons pas C ++ 20 avec une grande quantité de travail effectué, prêt à être publié, et ne faisons pas attendre le monde entier encore trois ans. Le retard ne bénéficiera pas à ces fonctionnalités, la plupart d'entre elles ou toutes ensemble.

Par conséquent, la phrase équivaut à «transformons C ++ 20 en C ++ 22 ou C ++ 23», et la réponse simple: «oui, nous aurons C ++ 23, mais en plus de C ++ 20, et pas à sa place. " Un délai C ++ 20 signifie ignorer C ++ 20 au lieu de publier un bon produit fini et stable, et cela ne sera pas avantageux.

Mais la fonctionnalité X est cassée / cela prend plus de temps qu'il ne nous en reste pour corriger les bugs en C ++ 20!

Pas question! Nous pouvons simplement le couper.

Dans ce cas, quelqu'un devra rédiger une lettre en EWG ou LEWG (selon la situation) avec une description de la situation et proposer de supprimer la fonctionnalité du projet de travail IS. Ces groupes considéreront l'appel, et s'ils décident que la fonctionnalité est cassée (et le plénum est d'accord avec eux), alors la fonctionnalité sera reportée jusqu'à la prochaine version C ++. Nous l'avons déjà fait avec les concepts C ++ 0x.

Mais dans le cas de (1), nous transférerons non seulement cette fonctionnalité, mais l' ensemble complet des fonctionnalités du C ++ 20 au C ++ 23! Ce serait ... un buste.

L'approche (2) signifie-t-elle des versions «majeures / mineures»?

Non. Au début, nous l'avons dit jusqu'à ce que nous réalisions que (2) signifie seulement que vous n'avez pas besoin de choisir un ensemble de fonctionnalités, même du point de vue de la version «principale / secondaire».

L'approche (2) signifie seulement «nous expédions ce qui est prêt». Les versions sont obtenues:

• la même taille (c'est-à-dire généralement moyenne) pour les fonctionnalités est «plus petite» car moins de temps est consacré à leur développement (disons moins de trois ans chacune), et en général, nous obtenons le même nombre de fonctionnalités terminées dans la version;
  
• et une taille variable (ce n'est pas nécessaire une ou deux fois) pour les fonctionnalités "plus grandes", qui prennent plus de temps (disons, plus de trois ans chacune), et chaque version du SI inclut autant de ces fonctionnalités qu'elles parviennent à compléter pour être publiées. Par conséquent, dans certaines versions, il y en a plus, dans d'autres moins.
  

C ++ 14 et C ++ 17 étaient relativement petits, car beaucoup d'efforts de normalisation ont été consacrés aux fonctionnalités de longue durée décrites dans les propositions d'implémentation (par exemple, les contrats) et aux «branches de fonctionnalités» dans TS (par exemple, les concepts).

C ++ 20 est une excellente version ...

Oui C ++ 20 possède de nombreuses fonctionnalités majeures. Trois des plus grands commencent par «ko» (concepts, contrats, coroutines), nous pourrions donc l'appeler co_cpp20. Ou co_dépendant.

... et ce n'est pas trop fait dans le cycle de trois ans pour C ++ 20?

Non, voir ci-dessus "une fois à la fois n'est pas nécessaire."

Le C ++ 20 est important non pas parce que nous avons fait plus en trois ans, mais parce qu'il y a beaucoup de longs développements (dont au moins deux sur lesquels nous travaillons sous la forme actuelle depuis 2012 sous la forme de phrases P et de branches TS ) ont atteint le stade de préparation et ils ont décidé de les inclure dans le projet de SI de la même version.

Presque toujours, les principales fonctionnalités sont développées depuis de nombreuses années. La principale différence entre l'approche (1) pour C ++ 98 et C ++ 11 et l'approche (2) est qu'en C ++ 98 et C ++ 11, la publication a été retardée jusqu'à ce que toutes ces fonctionnalités soient prêtes, et maintenant nous expédions dès que nous serons prêts, et avec eux, nous publierons beaucoup plus.

C ++ 20 a suivi le même cycle de trois ans que C ++ 14 et C ++ 17. Nous n'avons pas fait plus au cours des trois dernières années qu'au cours des deux cycles précédents, nous avons simplement ajouté plus aux principales caractéristiques. Si l'un d'eux n'était pas prêt, nous l'aurions jeté et terminé déjà pour C ++ 23. Si cela se produit, nous le signalerons dans la proposition de mise en œuvre et expliquerons les raisons.

C ++ 14 + 17 + 20 a constitué notre troisième cycle de neuf ans (2011-2020) après C ++ 98 (1989-1998) et C ++ 11 (2002-2011). Mais puisque nous avons adhéré à l'approche (2), nous avons également publié des développements qui étaient prêts pour la fin des cycles de trois et six ans.

N'est-il pas préférable d'attraper des bogues lorsqu'un produit est en cours de développement, et non après sa sortie?

Bien sûr, c'est mieux.

Mais si nous parlons des raisons du retard dans la publication de la norme C ++, alors cette question implique deux fausses hypothèses:

• qu'avant la publication de la norme, les fonctionnalités n'étaient pas sorties et n'étaient pas utilisées (pour beaucoup, il y a déjà de l'expérience en production);
  
• et que toutes les fonctionnalités peuvent être utilisées ensemble jusqu'à ce que la norme soit publiée (non autorisé).
  

J'explique:

1. La plupart des principales fonctionnalités de C ++ 20 ont été implémentées sous la forme dans laquelle elles sont reflétées dans le projet actuel de la norme dans au moins un compilateur, et dans la plupart des cas ont déjà été utilisées dans le code de production (c'est-à-dire qu'elles sont déjà disponibles pour les utilisateurs qui sont très satisfaits) . Par exemple, les coroutines (introduites seulement cinq mois avant cet article) ont été utilisées pendant deux ans en production chez MSVC et un an chez Clang, qui était très satisfait des gros clients (par exemple, Azure et Facebook).
2. Nous n'attraperons pas beaucoup de problèmes d'interaction entre les fonctionnalités jusqu'à ce que les utilisateurs commencent à les utiliser en production, c'est-à-dire avant la publication de la norme, car de nombreux développeurs attendront qu'elle soit publiée afin de mettre en œuvre différents projets. Et si nous montrons de l'incertitude quant au moment de la publication, ces implémentations seront également retardées. Eh bien, ils implémentent toujours quelque chose, mais beaucoup seront suspendus jusqu'à ce que les développeurs soient sûrs que nous sommes prêts à publier. Demandez aux créateurs de <nom du compilateur préféré> ce qui s'est passé lorsqu'ils ont implémenté <nom de la grande fonctionnalité> avant qu'il n'apparaisse dans la norme publiée. Dans de nombreux cas, il est nécessaire de mettre en œuvre à plusieurs reprises et de rompre les consommateurs à plusieurs reprises. Par conséquent, les développeurs préfèrent attendre que le comité approuve certaines fonctionnalités.

Enfin, n'oubliez pas le problème des fonctionnalités d'interaction. Nous ne les publions pas seulement lorsque nous sommes prêts, après cela, nous avons encore besoin de temps pour rechercher les problèmes d'interaction entre les fonctionnalités et ajouter le support de telles interactions, ce que nous ne pouvons tout simplement pas découvrir avant que les nouvelles fonctionnalités ne soient largement utilisées. Et peu importe à quel point nous retardons la publication de la norme, il y aura toujours des interactions que nous ne pourrons explorer que beaucoup plus tard. Vous devez gérer ce risque à l'aide d'une conception flexible, garantissant la compatibilité des fonctionnalités, et ne pas attendre pour vous débarrasser de tous les risques.

La norme ne sera jamais parfaite ... ne libérez-vous pas de bugs?

Oui

Si nous constatons que la fonctionnalité n'est pas prête, nous devons la supprimer de la version.

Si nous voyons qu'une fonctionnalité peut être meilleure et que nous savons que le changement peut s'avérer être rétrocompatible, alors ce n'est pas une raison pour refuser sa sortie maintenant. Il peut être publié en tant qu'extension dans le C ++ suivant.

Nous publions intentionnellement des fonctionnalités que nous prévoyons d'améliorer à l'avenir, tout en étant convaincus que nous pouvons maintenir la compatibilité descendante.

Mais ne devriez-vous pas essayer de minimiser les erreurs de publication?

Oui Nous essayons.

Mais nous n'essayons pas d'éviter tous les risques. Il y a aussi un risque et un prix (possible) de refuser de divulguer ce qui nous semble prêt. Et le plus souvent, nous avons raison.

Etes-vous sûr que maintenant la qualité est meilleure que d'utiliser l'approche (1)?

Oui

Selon des mesures objectives, le volume de commentaires de différents pays et les rapports de bogues, C ++ 14 et C ++ 17 étaient nos versions les plus stables, et selon ces mesures, ils étaient 3-4 fois plus élevés que C ++ 98 et C ++ 11. Et la raison réside précisément dans la régularité des versions, en plaçant les grandes fonctionnalités en premier dans les branches TS (y compris les descriptions complètes de leur intégration avec la norme principale) et dans leur infusion ultérieure, lorsque nous sommes convaincus de la disponibilité.

Depuis 2012, la norme principale a toujours été maintenue dans un état presque prêt à être expédié (donc même des ébauches de travail de la même qualité que les versions des normes C ++ 98 et C ++ 11). Cela ne s'est jamais produit auparavant, lorsque nous avons gardé le patient non sécurisé pendant une longue période, avec de longues listes de problèmes et d'organes répartis, que nous allons remettre bientôt. Maintenant, nous savons que nous pouvons maintenir un calendrier avec un travail de haute qualité, car nous restons toujours dans un état de préparation rapprochée pour la libération. Si vous le souhaitez, vous pouvez sortir un CD même maintenant, sans vous réunir à Cologne, et la qualité serait toujours beaucoup plus élevée que jamais avec un CD C ++ 98 ou C ++ 11 (en vérité, et leurs normes publiées) . Et étant donné que C ++ 98 et C ++ 11 ont réussi, la compréhension que maintenant la qualité est encore plus élevée signifie que nous sommes sur la bonne voie.

C ++ 98 et C ++ 11 ont été développés pendant environ 9 ans et étaient de très bons produits ...

Oui: 1989-1998 et 2002-2011.

... et C ++ 14 et C ++ 17 étaient des versions mineures. C ++ 20 est-il une version majeure?

Je répète, je pense qu'il est correct de comparer C ++ 14 + 17 + 20 dans son ensemble: c'est notre cycle de neuf ans, mais puisque nous avons adhéré à l'approche (2), nous avons également publié les développements qui étaient prêts à terminer les cycles de trois et six ans .

L'approche (2) vous permet d'atteindre des objectifs basés sur les fonctionnalités comme P0592 pour le prochain C ++?

Bien sûr! Bien qu'il n'y ait pas de mots comme «devrait inclure ces fonctionnalités», parce que ce sera l'approche (1).

Tendre vers un certain ensemble de fonctionnalités et donner la priorité à l'une d'entre elles est normal, mais c'est une question de priorité. Jusqu'à présent, nous ne prendrons que ce qui est prêt, mais nous pouvons d'abord choisir sur quoi travailler afin de nous préparer le plus rapidement possible.