C++-Schöpfer Bjarne Stroustrup stellt sich gegen das Komitee – und der DIS-Ballot scheitert

Dies ist eine gut geschriebene und recht diplomatische Zusammenfassung von Herb Sutter. Ich bin nicht tief genug in der Materie, um sicher zu sein, dass er recht hat, dass Stroustrups Opposition der Hauptgrund dafür war, dass die C++26-Abstimmung scheiterte, wo andere durchkamen, aber es klingt plausibel.

Es listet auch 6 mögliche Wege für C++26 mit Vor- und Nachteilen auf. Ich denke, sie sind ungefähr:

A. Auf einen offiziellen C++26-Standard verzichten, aber diese Features in C++29 aufnehmen.

B. Contracts aus C++26 entfernen und es verabschieden.

C. „Bitte“ sagen und erneut abstimmen.

D. Contracts bezüglich virtueller Funktionen anpassen und erneut abstimmen.

E. C++26 als viele verschiedene nationale Standards vieler Länder verabschieden statt als internationalen Standard.

F. E tun und außerdem erwägen, ISO zu verlassen und stattdessen zu ANSI/INCITS zu wechseln.

Ich denke, das misst diesem Ereignis und Bjarnes Position zu Contracts zu viel Gewicht bei.

Bjarnes Opposition gegen Contracts mag das Zünglein an der Waage gewesen sein, aber es gibt definitiv eine wachsende Müdigkeit (und Wachsamkeit) gegenüber großen, halbgebackenen Features, die als Übungsaufgaben für die Implementierer übrig gelassen werden (ich schaue dich an, Modules).

Diesen historischen Kontext bei der Analyse dieser Abstimmung zu ignorieren, scheint ein Fehler zu sein.

Ich habe C++ eine Weile nicht wirklich verfolgt (das letzte nette Feature, das ich gesehen habe, waren Concepts). Normalerweise genieße ich irgendwie das seltsame, ausdrucksstarke Code-Golf, das man mit den neuen Features schreiben kann. Zum Beispiel habe ich ausprobiert, Concepts zu verwenden, um sicherzustellen, dass Matrix-Dimensionen mit der gewünschten Operation kompatibel sind. Nicht wirklich nützlich, aber ein nettes Gedankenexperiment.

Aber diese vorgeschlagenen Contracts ... ich sehe nicht wirklich viel Nutzen gegenüber dem einfachen expliziten Schreiben eigener Assertions.

Ich nehme an, man kann die Anforderungen in den Deklarationen sehen, aber ich würde wetten, dass ausgefallene moderne C++-Deklarationen schnell so lang und verbose werden, dass man beim Lesen schnell ermüdet. Vielleicht sind sie im LLM-Zeitalter nützlicher?

Als jemand, der ein paar Wochen damit verbracht hat, in C++ einzusteigen (vor LLM, also vielleicht ist es jetzt besser?) und dann aus Verwirrung irgendwie aufgegeben hat, fand ich es wirklich schwierig, mit den vielen verschiedenen Arten umzugehen, etwas zu tun. Ich meine, welchen Pointer sollte ich verwenden? Wie sollte ich iterieren? Ich bin sicher, es gibt eine Antwort darauf, aber ich fand es einfach einfacher, zu Python zurückzukehren und Rust zu nutzen, wenn ich es brauchte.

Es scheint, als wäre ein Teil der Sorge, dass das Feature gleich beim ersten Mal richtig ausgeliefert werden muss, weil es ewig leben wird. Vielleicht könnte es helfen, Features zu erlauben, veraltet zu werden und dann entfernt zu werden?

Aber ich weiß nicht, ich habe noch nichts geschrieben, das 36 Jahre überdauert hat, also ist der aktuelle Ansatz vielleicht der beste!

Ich wollte nur kurz vorbeikommen und sagen, dass Sutter nicht nur recht hat, Bjarnes Position hier zu wiederholen, sondern auch der Autor des meiner Meinung nach einflussreichsten Papers zum Fortschritt der Hardwareleistung und dem Wandel zur nebenläufigen Ausführung ist: https://www.cs.utexas.edu/~lin/cs380p/Free_Lunch.pdf

36 Jahre anhaltende Übereinstimmung ist nicht gut; es bedeutet, dass niemand zu irgendetwas Nein sagt, und man hat einen riesigen, schmutzigen Schneeball, der einen Berg hinunterrollt.

Ich bin sicher, ich bin nicht der Einzige, aber ich habe das Gefühl, dass C++ vorbei/erledigt ist. Ich arbeite in einer C++-Codebasis und mache seit über 20 Jahren C++, und zumindest für mich steht die Schrift an der Wand.

1. C++ ist unsicher. Bjarne hält ständig Vorträge, die im Grunde sagen: „Benutze es perfekt und mache keine Fehler, dann ist es sicher.“ Das ist nicht mehr nützlich. In einer Welt, in der LLMs jeden Fehler finden können, um ihn auszunutzen, kämpfen alle C++-Projekte, Schritt zu halten, und sie in C++ zu belassen, garantiert praktisch, dass es in Zukunft mehr Exploits geben wird. Ja, nicht jeder Bug wird durch den Wechsel zu einer sichereren Sprache gelöst, aber die Angriffsfläche in der neuen Realität zu reduzieren, kann nicht länger aufgeschoben werden.

2. LLMs können umschreiben. Die früheren Argumente waren: „Es gibt C++-Legacy-Codebasen, also wird C++ niemals sterben.“ Das war ein gültiges Argument, bevor ein LLM einfach alles umschreiben würde. Ich verstehe, dass Leute sagen werden, sie seien nicht perfekt, aber Menschen sind es auch nicht. Außerdem werden sie ständig besser, und wir sehen ihren Fortschritt. Leute, die ein LLM auf irgendein Projekt ansetzen und es zauberhaft auf irgendeiner anderen Plattform zum Laufen bringen usw. ... Es ist klar, dass es passiert.