Eind 2022 schreef Kris van Rens over de staat van C++ op dat moment en de uitdagers. Een vervolg na nog eens twee jaar.
In 2022 trok Google, uit onvrede met het evolutieproces van C++, een aanzienlijk deel van zijn middelen terug uit het werk aan C++ en de Clang compiler front-end. Als alternatief werd het langetermijnproject Carbon aangekondigd, een opvolgertaal die nauw kan samenwerken met C++. Dit en de daaropvolgende gebeurtenissen vormden een keerpunt voor C++, omdat het ernstige kritiek te verduren kreeg vanwege de opgebouwde technische schuld en het relatief trage ontwikkelingstempo. Vanaf dat moment leek het erop dat iedereen een (sterke) mening had en deze luid verkondigde – de hoeveelheid kritiek kon niet langer worden genegeerd door het C++ comité.
Een ander aspect van C++ dat onder vuur ligt is het gebrek aan geheugenveiligheid. Geheugenveiligheid in een programmeertaal verwijst naar de mogelijkheid om fouten te voorkomen of op te vangen die gerelateerd zijn aan onjuiste geheugentoegang, zoals buffer overflows, use-after-free bugs of bungelende pointers, door ingebouwde functies en garanties in de taal zelf. Dit kan worden uitgebreid naar algemene taalveiligheid waarbij alle ongedefinieerd gedrag en ongespecificeerde semantiek uit de taal wordt geëlimineerd. Taalveiligheid is een concept gedefinieerd op een spectrum in plaats van een binaire eigenschap; sommige talen zijn veiliger dan andere. Voorbeelden van talen die als veilig worden beschouwd en nog steeds relatief low-level zijn Swift, Ada en Rust.
Na de intense spreekwoordelijke hitte van de zomer van 2022, zette een reeks klappen in verschillende vormen van openbare adviezen over geheugenveiligheid zowel C als C++ expliciet in slecht daglicht. Eind 2022 kwam eerst de NSA met een witboek waarin ons werd aangespoord om af te stappen van C en C++. Daarna begon CISA (de Amerikaanse Cybersecurity Infrastructure Security Agency) te pleiten voor een routekaart voor geheugenveiligheid. In 2023 en 2024 verkondigden zelfs het Witte Huis en US Consumer Report dat we geheugenveiligheid serieuzer dan ooit moeten nemen en moeten overstappen op geheugenveilige talen. Er waren nog veel meer gebeurtenissen, maar het volstaat te zeggen dat ze allemaal niet onopgemerkt zijn gebleven voor de C++-commissie.
''C is quite a simple language; it’s easy to learn and get started with. However, it’s very hard to become advanced and proficient at it at scale.''
Toegegeven, sommige van de pogingen van de C++ commissieleden om de aanvallen van het publiek te weerleggen kwamen een beetje minachtend over, waarbij geheugenveiligheid vaak bijna werd gebagatelliseerd als “slechts één van de vele potentiële softwareproblemen”. Dit klinkt voor mij heel erg als een logische denkfout. Natuurlijk kunnen er veel dingen fout gaan en een veilige taal is geen wondermiddel. De eisen voor softwareontwikkeling zijn echter drastisch veranderd in de afgelopen veertig jaar en tegenwoordig is geheugenveiligheid een opgelost probleem voor veel andere talen die bruikbaar zijn in hetzelfde toepassingsdomein. Officieel heeft ISO werkgroep 21 (WG21) studiegroep 23 (SG23) opgericht voor “Veiligheid en beveiliging”, met de taak om de beste manieren te vinden om van C++ een veiligere taal te maken en tegelijkertijd de andere beperkingen zoals achterwaartse compatibiliteit te behouden – niet zo eenvoudig.
Onmiskenbare kloof
Ik heb de afgelopen decennia met verschillende programmeertalen tegelijk in productie gewerkt. Wat me echt opvalt aan al mijn ervaringen met C en C++ is de enorme cognitieve belasting die ze op ontwikkelaars leggen.
C is een vrij eenvoudige taal; het is makkelijk te leren en om mee te beginnen. Het is echter erg moeilijk om er op grote schaal geavanceerd en bedreven in te worden. Als eenvoudige taal dwingt het je om veel belangrijke foutgevoelige engineeringtaken zoals geheugenbeheer en goede foutafhandeling handmatig uit te voeren – hoofdaspecten van betrouwbare, bugvrije software. Er is veel controle op laag niveau, ja, maar de ceremonie en cognitieve last om dingen goed te krijgen is gewoon onthutsend.
Hetzelfde geldt grotendeels voor C++. Het maakt dingen wel beter door je te ondersteunen bij het schrijven van correcte code, bijvoorbeeld met de standaardbibliotheek met slimme pointers voor geheugenbeheer. De vrachtwagenladingen taalcomplexiteit maken het echter ook moeilijk om het correct op schaal te gebruiken.
Bovendien hebben al deze aspecten van het coderen in C en C++ geen garantie dat de dingen betrouwbaar zijn na compilatie. Dit dwingt ontwikkelaars om best practices te bestuderen, compiler sanitizers en static analyzers te gebruiken en hun toevlucht te nemen tot uitgebreide tests, alleen maar om er zeker van te zijn dat alles in orde is. Natuurlijk zouden de meeste van deze activiteiten deel moeten uitmaken van elke gezonde mindset van softwareontwikkelaars, maar het is pijnlijk om te beseffen dat C en C++ de vereiste om dit werk te doen overdragen aan de ontwikkelaar, in plaats van het direct in de taal aan te pakken. Het ontwikkelen van een taal is, net als elke andere technische uitdaging, een eindeloze opeenvolging van afwegingen, dat is zeker, maar er is een onmiskenbaar gat tussen de mogelijkheden van de ‘oude talen’ en de behoeften op het gebied van softwareontwikkeling op dit moment. Andere, nieuwere talen laten zien dat het mogelijk is om aan deze eisen te voldoen terwijl het prestatiepotentieel behouden blijft.
''New features improve the language but also inherently increase the already quite substantial complexity, while all the old footguns and dangers like undefined behavior are still there.''
Jaren weg
De meeste programmeertalen worden in de loop der tijd voortdurend verbeterd. Als je echter in de C-wereld zit, zal er waarschijnlijk weinig tot niets veranderen. Voor veel projecten vandaag de dag is het daarom niet de juiste taalkeuze als je ook maar enige taalveiligheid wilt. Er zijn alternatieven beschikbaar die beter geschikt zijn voor het doel – als dit mogelijk is gezien de beperkingen en voorkeuren van uw project.
Voor C++ is het een ander verhaal. WG21 bereidt zich nu voor op de release van C++26, die enorme mogelijkheden gaat bieden, waaronder (hoogstwaarschijnlijk) contracten, executors en zelfs statische reflectie. Game-changers zeker, maar vooral gericht op het toepassingspotentieel van de taal of, in het geval van contracten, het verbeteren van de veiligheid en correctheid, maar nog steeds ten koste van de handmatige arbeid van de ontwikkelaar die het gebruikt.
Nieuwe functies verbeteren de taal, maar vergroten inherent ook de toch al aanzienlijke complexiteit, terwijl alle oude voetzoekers en gevaren zoals ongedefinieerd gedrag er nog steeds zijn. Het onderwijzen van C++ aan beginners als trainer blijft, voor een deel, een oefening in het wegsturen van de valkuilen – niet echt een natuurlijke, handige manier om te onderwijzen of te leren.
Het ‘parallelle universum’ van de taal Circle C++ laat zien hoe de ogenschijnlijk verstopte syntaxis en taaldefinitie van C++ toch in staat is om veel andere geweldige functies in te bouwen, zoals echte enumerators, pattern matching, statische reflectie en zelfs een borrow checker. Helaas is deze opmerkelijke eenmansshow van Sean Baxter niet gestandaardiseerd in C++ (en vice versa). De kans is klein dat een van deze uitstekende functies binnenkort in het officiële C++ terecht zal komen.
Baxter heeft ook een “Safe C++” voorstel, gepresenteerd aan de Safety and Security studiegroep in november vorig jaar. Hierin stelt hij voor om C++ uit te breiden met een “rigoureus veilige subset” van de taal die dezelfde veiligheidsgaranties biedt als de Rust borrow checker doet. Ik juich de inspanning toe, maar de tijd zal leren of, en in welke vorm, dit voorstel zijn weg zal vinden door het vaak schijnbaar trage C++ taalontwikkelingsproces. Het ontwerp van C++26 is grotendeels naar elkaar toegegroeid en C++29 is nog een paar jaar verwijderd. Tel daarbij op de implementatie/industrialisatie tijd van deze spec versies voordat ze echt op onze virtuele werkbanken landen, en het zou wel eens een decennium vanaf nu kunnen worden – als we geluk hebben.
Groenere weiden
Maar niet alles is verloren. De C++ commissie doet geweldig werk om de taal vooruit te helpen en de huidige staat van de taal en het ecosysteem is beter dan ooit. Het is alleen zo dat de kloof tussen wat C++ vandaag de dag kan bieden in vergelijking met wat mogelijk is gebleken op het gebied van veiligheid van systeemprogrammering en geïntegreerde tooling enorm is.
Als ik een paar jaar vooruit kijk, zie ik dit gat nog niet gedicht worden. Ondertussen staan talen als Rust en Swift niet stil. Er is veel momentum en toewijding voor C++ in de wereld, waardoor de industrie eraan vasthoudt, maar hoe lang kan het de technologiekloof in stand houden voordat industrieën of applicatiedomeinen overstappen op groenere weiden?
De training van Kris van Rens is één keer per jaar beschikbaar.
Blijf op de hoogte
Ontvang onze maandelijkse updates
