Entwurf einer FAQ: Warum erscheinen alle drei Jahre C ++ - Standards?

WG21 hat alle drei Jahre einen strengen Zeitplan (siehe P1000 ) für die Standardversion. Und keine Verzögerungen.

Während jedes Zyklus erhalten wir regelmäßig Fragen „Warum ist es so streng?“, Insbesondere von neuen Mitgliedern des Ausschusses, die mit seiner Geschichte und den Gründen für den aktuellen Stand der Dinge nicht vertraut sind. Während einer vorläufigen Telefonkonferenz mit der Kölner Verwaltung empfahlen mehrere Personen zu beschreiben, warum wir dies tun und wie die Entscheidung getroffen wurde, diesen Zeitplan zu übernehmen.

Ich habe das alles in Form von Fragen und Antworten für den nächsten Entwurf von P1000 gemalt und den Ausschussmitgliedern auf ihrem Weg nach Köln eine Kopie geschickt. Dieses Material wird in der nächsten öffentlichen Version von P1000 veröffentlicht, wir werden es in einigen Wochen ab dem aktuellen Moment senden.

Der Entwurf der FAQ kann jedoch für die Öffentlichkeit von Interesse sein, daher biete ich Ihnen eine Kopie davon an. Ich hoffe, dass es Ihnen größtenteils nützlich sein wird, in gewisser Weise aufklären und vielleicht sogar ein bisschen unterhalten wird.

Es gibt Fehler im Standard, sollten Sie C ++ 20 verschieben?

Natürlich ja und nein.

Wir bewegen uns mit einer bestimmten Geschwindigkeit in eine bestimmte Richtung: Für das letzte Jahr sind Fehlerkorrekturen geplant, daher legt der Zeitplan in C ++ „19“ (Kona) eine Frist fest, um das Hinzufügen von Features (Einfrieren von Features) in C ++ „20“ zu stoppen Wir hatten ein Jahr Zeit, um Fehler zu beheben, einschließlich der Arbeit mit Kommentaren aus verschiedenen Ländern in diesem Sommer. Vor Beginn des Jahres 2020 (Treffen in Köln, Belfast und Prag) müssen wir Feedback geben und andere Lösungen für Probleme sowie Fehlerbehebungen anwenden.

Wenn wir ein oder zwei weitere Besprechungen haben, können wir einen <Feature-Namen> hinzufügen, der fast fertig ist. Sollten Sie also C ++ 20 verschieben?

Natürlich ja und nein.

Warten Sie, bis ein paar weitere Besprechungen stattfinden (nach Prag), und C ++ 23 wird für den Geschäftsbetrieb geöffnet sein. Zunächst werden wir dafür stimmen, dem Funktionsentwurf von C ++ 23 <Feature-Name> hinzuzufügen. Dies haben wir mit den Konzepten gemacht: Sie waren nicht bereit für den Übergang von TS direkt zu C ++ 17. Daher stimmten sie beim ersten Treffen zu C ++ 20 (in Toronto) dafür, die Grundfunktionalität von Konzepten auf den Entwurf von C ++ 20 zu übertragen, der viel Zeit gab, um den Rest des widersprüchlichen Teils der eingeführten TS (Nicht-Template-Syntax) zu verbessern und zu verfeinern nächstes Jahr (San Diego). Jetzt ist die gesamte Funktionalität bereit.

Dies scheint zu streng zu sein. Warum IS-Releases in festgelegten Intervallen (drei Jahre) veröffentlichen?

Denn im Fall der Veröffentlichung von C ++ IS ist dies eine der beiden Hauptoptionen für das Projektmanagement, und die Erfahrung zeigt, dass diese Option besser ist als die zweite.

Welche zwei Optionen für das Projektmanagement gibt es für die Veröffentlichung von C ++ IS?

Ich bin froh, dass du gefragt hast.

Bei einer Veröffentlichung gibt es zwei Hauptoptionen: Wählen Sie eine Funktion oder ein Veröffentlichungsdatum aus. Wenn Sie eine auswählen, verlieren Sie die Kontrolle über die Definition der anderen. Sie können nicht beide gleichzeitig steuern. Kurzum:


Ich erkläre:

(1) "Was": Wir wählen Funktionen aus und versenden als bereit, ohne dass eine Release-Zeit gewählt werden muss . Wenn sich herausstellt, dass Sie mehr Zeit benötigen, um ein Feature aus dem Standardentwurf fertigzustellen, muss die ganze Welt auf Sie warten. Sie arbeiten an großen Funktionen, die mehrere Jahre Entwicklungszeit erfordern, und versuchen dann, die Arbeit an neuen Funktionen überhaupt einzustellen, während Sie die Version stabilisieren.

So war es mit C ++ 98 (es wurde um 1994 erwartet, Björn sagte, wenn die Veröffentlichung bis dahin nicht herauskommen würde, wäre es ein Fehler) mit C ++ 11 (es wurde 0x genannt, weil x bis 2007 erwartet wurde ) Dies ist ein Ansatz, bei dem der Patient auf unbestimmte Zeit ungeschirmt bleibt, was zu einer Verzögerung bei den Integrationstests und der Freigabe führte. Dies wiederum führte zu großer Marktunsicherheit hinsichtlich des Zeitpunkts des nächsten Standards und der Frage, ob dieser überhaupt veröffentlicht wird (ja, nicht nur die Entwicklungsteilnehmer, sondern auch einige Mitglieder des Ausschusses, die 1996 und 2009 ernsthaft angezweifelt wurden, werden auftauchen Gibt es relevante Releases? Mehrere Jahre lang erfüllten die meisten Compiler den Standard nicht, weil niemand wusste, wie viele inkompatible Änderungen das Komitee in der neuen Version einführen würde, oder wann dies überhaupt zu erwarten wäre. Dies hat zu einer Vielzahl und Fragmentierung der C ++ - Unterstützung in Compilern geführt, die der Community zur Verfügung stehen.

Warum haben wir das getan, sind wir Idioten? Nicht wirklich, sie waren nur unerfahren und ... sagen wir "optimistisch". Es war eine Straße, die mit besten Absichten gepflastert war. In den Jahren 1994-1996 und 2007-2009 glaubten wir wirklich, dass wir jetzt ein, zwei oder drei weitere Sitzungen verschieben und alles tun würden, und jedes Mal würden sie um bis zu vier Jahre verschoben. Und jetzt haben sie aus eigener Erfahrung gesehen, dass es für ein oder zwei Jahre keinen Transfer geben kann.

Glücklicherweise hat sich dank Option (2) alles geändert.

(2) „Wann“: Wir wählen das Veröffentlichungsdatum aus und versenden die bereitgestellten Funktionen. Sie müssen keine Funktionen auswählen . Wenn sich herausstellt, dass mehr Zeit benötigt wird, um ein Feature aus einem Standardentwurf zu verfeinern, verwerfen wir es und versenden, was fertig ist. Sie können weiterhin an großen Funktionen arbeiten, deren Erstellung wie bei mehreren Releases einige Zeit in Anspruch nimmt. Sie können dies jedoch in "Zweigen" von Drittanbietern tun und diese so bald wie möglich dem IS-Hauptzweig hinzufügen. Und Sie arbeiten ständig an Features, da deren Entwicklung völlig unabhängig von der aktuellen Version ist (es gibt keinen großen Verbindungspunkt).

Wir halten seit 2012 an diesem Ansatz fest und wollen ihn nicht aufgeben. Dies ist ein „regelmäßig vernähter Patient“ -Ansatz, der aufgrund erzwungener regelmäßiger Integrationen und der Weigerung, dem IS-Entwurf Arbeit hinzuzufügen, bis er ein bestimmtes Stabilitätsniveau erreicht, normalerweise innerhalb des Feature-Zweigs, eine höhere Qualität erwartet. Es schafft auch einen vorhersehbaren Veröffentlichungszyklus, auf den sich der Markt verlassen kann. Im Laufe der Jahre begannen Autoren von Compilern nach der nächsten Veröffentlichung immer früher, Versionen ihrer Produkte zu veröffentlichen, die dem Standard entsprachen, was noch nie zuvor geschehen war. Und im Jahr 2020 erwarten wir die Veröffentlichung vollständig konformer Implementierungen in einem Jahr mit der Veröffentlichung des Standards, was auch noch nie zuvor geschehen ist. Dies ist nur zum Nutzen des gesamten Marktes - Entwickler, Benutzer, Lehrer.

Beachten Sie auch, dass wir seit Beginn dieses Ansatzes mehr tun (gemessen an großen, mittleren und kleinen Merkmalen) und mit höherer Qualität (gemessen an einer strikten Reduzierung der Anzahl von Fehlerberichten und Kommentaren zu) Entwürfe jeder Norm). Obwohl wir versenden, was wir vorbereitet haben (und wenn wir etwas nicht geschafft haben, versenden wir es nicht).

Wie ernst nehmen Sie Ansatz (2)? Wenn laut einem maßgeblichen Mitglied des Komitees ein großes Feature „fast fertig“ ist, werden Sie versucht sein, ein bisschen zu warten, oder?

Sehr ernst und nein.

Wir haben Statistiken: 2016, als wir uns in Jacksonville endgültig für Funktionen für C ++ 17 entschieden haben, sprach Björn Straustrup auf einer Plenarsitzung mit einem Vorschlag, Konzepte in C ++ 17 aufzunehmen. Als kein Konsens erzielt wurde, wurde Straustrup direkt gefragt, ob er die Veröffentlichung von C ++ 17 um ein Jahr verzögern möchte, um Konzepte aufzunehmen. Björn antwortete ohne zu zögern und auszuweichen mit „Nein“ und fügte hinzu, dass C ++ 17 ohne Konzepte wichtiger sei als C ++ 18 oder C ++ 19 mit Konzepten, obwohl Straustrup seit etwa 15 Jahren daran arbeite. Die Wahl war folgende: (2) Wir veröffentlichen C ++ 17 ohne Konzepte und dann C ++ 20 mit Konzepten (was wir getan haben) oder (1) wir benennen C ++ 17 in C ++ 20 um, was isomorph ist (2). mit Ausnahme des Überspringens von C ++ 17 und der Weigerung, das freizugeben, was bereits für C ++ 17 bereit war.

Was ist mit dem Kompromiss zwischen (1) und (2)? Angenommen, wir halten uns normalerweise an (2), aber mit „wenig“ Flexibilität, um „ein wenig“ zusätzliche Zeit zu erhalten, wenn Sie die Funktion verfeinern müssen?

Nein, denn es stellt sich heraus (1).

Fred Brooks erklärte im Monat des mythischen Mannes im Volksmund „die mythische kleine Übertragung“ und schloss daraus: „ Erlaube keine kleinen Übertragungen .“

Stellen Sie sich vor, wir haben C ++ 20 portiert. Wir müssten von (2) nach (1) zurückkehren, egal wie sehr wir uns bemühen, dies zu vermeiden, und würden gleichzeitig keine Vorteile erhalten. Wenn wir C ++ 20 verschieben würden, um es zu polieren, würden wir den Standard um mindestens zwei Jahre verzögern. Es gibt keine Konzepte wie die Übertragung von einem oder drei Meetings, da andere während dieser Zeit (ziemlich) weiter sagen: "Nun, mein Feature benötigt nur noch ein Meeting, wir haben es immer noch neu geplant, lassen Sie uns ein anderes übertragen." Und wenn wir mindestens zwei Jahre übertragen, bedeutet dies, dass C ++ 20 zu C ++ 22 und höchstwahrscheinlich zu C ++ 23 wird ... aber wir werden bereits C ++ 23 ausliefern! - Das heißt, wir werden auf jeden Fall C ++ 23 ausliefern, und der einzige Unterschied besteht darin, dass wir C ++ 20 nicht mit viel Arbeit übertragen, bereit zur Veröffentlichung sind und nicht die ganze Welt weitere drei Jahre warten lassen. Eine Verzögerung kommt diesen Funktionen nicht zugute, die meisten von ihnen oder alle zusammen.

Daher ist der Satz gleichbedeutend mit "Lassen Sie uns C ++ 20 in C ++ 22 oder C ++ 23 verwandeln" und der einfachen Antwort darauf: "Ja, wir werden C ++ 23 haben, aber zusätzlich zu C ++ 20 und nicht an seiner Stelle. " Eine C ++ 20-Verzögerung bedeutet, dass C ++ 20 übersprungen wird, anstatt ein gutes, stabiles und fertiges Produkt freizugeben, und dies hat keinen Nutzen.

Aber Feature X ist kaputt / es dauert länger als wir, um Fehler in C ++ 20 zu beheben!

Keine Frage! Wir können es einfach schneiden.

In diesem Fall muss jemand einen Brief in EWG oder LEWG (je nach Situation) mit einer Beschreibung der Situation schreiben und anbieten, die Funktion aus dem Arbeitsentwurf IS zu entfernen. Diese Gruppen werden den Einspruch prüfen. Wenn sie entscheiden, dass die Funktion fehlerhaft ist (und das Plenum mit ihnen übereinstimmt), wird die Funktion auf die nächste C ++ - Version verschoben. Wir haben dies bereits mit C ++ 0x-Konzepten gemacht.

Im Fall von (1) übertragen wir jedoch nicht nur diese Funktion, sondern den gesamten Funktionsumfang von C ++ 20 auf C ++ 23! Das wäre ... Pleite.

Bedeutet Ansatz (2) "Haupt- / Nebenversionen"?

Nein. Zuerst haben wir dies gesagt, bis wir festgestellt haben, dass (2) nur bedeutet, dass Sie selbst aus Sicht der Haupt- / Nebenversion keine Reihe von Funktionen auswählen müssen.

Ansatz (2) bedeutet nur "wir versenden, was fertig ist". Veröffentlichungen werden erhalten:

• Die gleiche Größe (dh normalerweise der Durchschnitt) für Features ist „kleiner“, da weniger Zeit für deren Entwicklung aufgewendet wird (z. B. jeweils weniger als drei Jahre), und im Allgemeinen erhalten wir die gleiche Anzahl abgeschlossener Features in der Version.
  
• und eine variable Größe (nicht ein- oder zweimal erforderlich) für "größere" Funktionen, die mehr Zeit in Anspruch nehmen (z. B. jeweils mehr als drei Jahre), und jede IS-Version enthält so viele dieser Funktionen, wie sie für die Veröffentlichung fertigstellen können. Daher gibt es in einigen Versionen mehr, in anderen weniger.
  

C ++ 14 und C ++ 17 waren relativ klein, da viel Standardisierungsaufwand für langwierige Funktionen aufgewendet wurde, die in Implementierungsvorschlägen (z. B. Verträge) und „Feature-Zweigen“ in TS (z. B. Konzepte) beschrieben sind.

C ++ 20 ist eine großartige Veröffentlichung ...

Ja C ++ 20 bietet viele wichtige Funktionen. Drei der größten beginnen mit „ko“ (Konzepte, Verträge, Coroutinen), also könnten wir es co_cpp20 nennen. Oder co_dependent.

... und wird im Dreijahreszyklus für C ++ 20 nicht zu viel getan?

Nein, siehe oben "einmalig ist nicht notwendig."

C ++ 20 ist groß, nicht weil wir in drei Jahren mehr getan haben, sondern weil es viele lange Entwicklungen gibt (darunter mindestens zwei, an denen wir in der aktuellen Form seit 2012 in Form von P-Sätzen und TS-Zweigen arbeiten ) erreichten das Stadium der Bereitschaft und beschlossen, sie in den Entwurf des IS derselben Veröffentlichung aufzunehmen.

Fast immer werden die Hauptmerkmale seit vielen Jahren entwickelt. Der Hauptunterschied zwischen Ansatz (1) für C ++ 98 und C ++ 11 und Ansatz (2) besteht darin, dass in C ++ 98 und C ++ 11 die Veröffentlichung verzögert wurde, bis alle diese Funktionen bereit waren, und jetzt werden wir groß ausgeliefert Sobald wir fertig sind und zusammen mit ihnen werden wir noch viel mehr veröffentlichen.

C ++ 20 durchlief denselben Dreijahreszyklus wie C ++ 14 und C ++ 17. Wir haben in den letzten drei Jahren nicht mehr getan als in den beiden vorherigen Zyklen. Wir haben lediglich mehr zu den Hauptfunktionen hinzugefügt. Wenn einer von ihnen nicht bereit wäre, hätten wir ihn weggeworfen und bereits für C ++ 23 fertiggestellt. In diesem Fall werden wir dies im Umsetzungsvorschlag melden und die Gründe erläutern.

C ++ 14 + 17 + 20 bildete unseren dritten Neunjahreszyklus (2011-2020) nach C ++ 98 (1989-1998) und C ++ 11 (2002-2011). Da wir uns jedoch an Ansatz (2) hielten, veröffentlichten wir auch Entwicklungen, die für das Ende von Drei- und Sechsjahreszyklen bereit waren.

Ist es nicht besser, Fehler zu erkennen, wenn sich ein Produkt in der Entwicklung befindet, und nicht, nachdem es veröffentlicht wurde?

Natürlich ist es besser.

Wenn wir jedoch über die Gründe für die Verzögerung bei der Veröffentlichung des C ++ - Standards sprechen, impliziert diese Frage zwei falsche Annahmen:

• dass vor der Veröffentlichung des Standards keine Funktionen herauskamen und nicht verwendet wurden (für viele gibt es bereits Erfahrung in der Produktion);
  
• und dass alle Funktionen zusammen verwendet werden können, bis der Standard freigegeben wird (nicht zulässig).
  

Ich erkläre:

1. Die meisten Hauptfunktionen von C ++ 20 wurden in der Form implementiert, in der sie sich im aktuellen Entwurf des Standards in mindestens einem Compiler widerspiegeln, und wurden in den meisten Fällen bereits im Produktionscode verwendet (dh sie sind bereits für Benutzer verfügbar, die sehr zufrieden sind). . Zum Beispiel wurden Coroutinen (nur fünf Monate vor diesem Artikel eingeführt) zwei Jahre lang in der Produktion bei MSVC und ein Jahr lang bei Clang verwendet, was bei großen Kunden (z. B. Azure und Facebook) sehr zufrieden war.
2. Wir werden nicht viele Probleme bei der Interaktion zwischen Features feststellen, bis Benutzer sie in der Produktion verwenden, dh bevor der Standard veröffentlicht wird, da viele Entwickler darauf warten, dass er veröffentlicht wird, um verschiedene Projekte zu implementieren. Und wenn wir Unsicherheit über den Zeitpunkt der Veröffentlichung zeigen, werden sich diese Implementierungen ebenfalls verzögern. Nun, sie implementieren immer noch etwas, aber vieles wird angehalten, bis die Entwickler sicher sind, dass wir bereit sind, es zu veröffentlichen. Fragen Sie die Ersteller von <Name des bevorzugten Compilers>, was passiert ist, als sie <Name des großen Features> implementiert haben, bevor es im veröffentlichten Standard erscheint. In vielen Fällen ist es notwendig, wiederholt zu implementieren und Verbraucher wiederholt abzubrechen. Daher warten Entwickler lieber darauf, dass das Komitee bestimmte Funktionen genehmigt.

Vergessen Sie nicht das Problem der Interaktionsfunktionen. Wir veröffentlichen sie nicht nur, wenn wir bereit sind. Danach brauchen wir noch Zeit, um nach Interaktionsproblemen zwischen Features zu suchen und Unterstützung für solche Interaktionen hinzuzufügen, die wir einfach nicht herausfinden können, bevor neue Features weit verbreitet werden. Und es spielt keine Rolle, wie sehr wir die Veröffentlichung des Standards verzögern, es wird immer Interaktionen geben, die wir erst viel später untersuchen können. Sie müssen dieses Risiko mithilfe eines flexiblen Designs verwalten, die Kompatibilität der Funktionen sicherstellen und nicht warten, bis alle Risiken beseitigt sind.

Der Standard wird niemals perfekt sein ... veröffentlichen Sie keine Fehler?

Ja

Wenn wir feststellen, dass die Funktion nicht bereit ist, müssen wir sie aus der Version entfernen.

Wenn wir sehen, dass eine Funktion besser sein kann und wir wissen, dass sich die Änderung als abwärtskompatibel herausstellen kann, ist dies kein Grund, ihre Veröffentlichung jetzt abzulehnen. Es kann als Erweiterung im folgenden C ++ veröffentlicht werden.

Wir veröffentlichen absichtlich Funktionen, die wir in Zukunft verbessern möchten, und sind zuversichtlich, dass wir die Abwärtskompatibilität beibehalten können.

Aber sollten Sie nicht versuchen, Release-Fehler zu minimieren?

Ja Wir versuchen es.

Wir versuchen jedoch nicht, alle Risiken zu vermeiden. Es besteht auch das Risiko und der (mögliche) Preis, sich zu weigern, das zu veröffentlichen, was uns bereit erscheint. Und meistens haben wir recht.

Sind Sie sicher, dass die Qualität jetzt besser ist als mit dem Ansatz (1)?

Ja

Gemäß objektiven Metriken waren die Anzahl der Kommentare aus verschiedenen Ländern und Fehlerberichte, C ++ 14 und C ++ 17, unsere stabilsten Versionen, und nach diesen Metriken waren sie 3-4-mal höher als C ++ 98 und C ++ 11. Und der Grund liegt genau in der Regelmäßigkeit der Veröffentlichungen, in der Platzierung großer Funktionen in TS-Filialen (einschließlich vollständiger Beschreibungen ihrer Integration in den Hauptstandard) und in ihrer anschließenden Infusion, wenn wir von der Bereitschaft überzeugt sind.

Seit 2012 wird der Hauptstandard immer in einem fast versandfertigen Zustand gehalten (also auch Arbeitsentwürfe von der gleichen hohen Qualität wie die Versionen der Standards C ++ 98 und C ++ 11). Dies war noch nie zuvor der Fall, als wir den Patienten lange Zeit ungesichert hielten und lange Listen mit Problemen und Organen verteilten, die wir bald zurückstellen werden. Jetzt wissen wir, dass wir einen Zeitplan mit qualitativ hochwertiger Arbeit einhalten können, da wir immer in einem Zustand enger Bereitschaft zur Veröffentlichung bleiben. Wenn Sie möchten, können Sie auch jetzt noch eine CD veröffentlichen, ohne sich in Köln zu treffen, und dennoch wäre die Qualität mit einer CD C ++ 98 oder C ++ 11 (in Wahrheit und ihren veröffentlichten Standards) viel höher als je zuvor. . Und wenn man bedenkt, dass C ++ 98 und C ++ 11 erfolgreich waren, bedeutet das Verständnis, dass die Qualität jetzt noch höher ist, dass wir auf dem richtigen Weg sind.

C ++ 98 und C ++ 11 wurden für ungefähr 9 Jahre entwickelt und waren sehr gute Produkte ...

Ja: 1989-1998 und 2002-2011.

... und C ++ 14 und C ++ 17 waren Nebenversionen. Ist C ++ 20 eine Hauptversion?

Ich wiederhole, ich glaube, es ist richtig, C ++ 14 + 17 + 20 als Ganzes zu vergleichen: Dies ist unser Neunjahreszyklus, aber da wir uns an Ansatz (2) gehalten haben, haben wir auch die Entwicklungen veröffentlicht, die bereit waren, die Dreijahres- und Sechsjahreszyklen abzuschließen .

Ansatz (2) ermöglicht es Ihnen, funktionsbasierte Ziele wie P0592 für das nächste C ++ zu erreichen?

Natürlich! Es gibt zwar keine Wörter wie "sollte diese Merkmale enthalten", denn dann wird es der Ansatz sein (1).

Es ist normal, nach bestimmten Funktionen zu streben und einer davon Priorität einzuräumen, aber dann ist es eine Frage der Priorität. Bisher werden wir nur das nehmen, was fertig ist, aber wir können zunächst auswählen, woran wir arbeiten möchten, um uns so schnell wie möglich vorzubereiten.