Het gebruik van C++ in Linux is opnieuw voorgesteld
Het lijkt erop dat de introductie van Rust als tweede taal programmeren in de Linux Kernel heeft een van de belangrijkste veranderingen vertegenwoordigd die Linux heeft gehad en dan heb ik het niet over de reikwijdte van features en functionaliteiten, maar het heeft een zeer belangrijk startpunt gemarkeerd in de manier waarop Linus Torvalds en het ontwikkelingsteam een belangrijke stap hebben gezet in de richting van het ten goede moderniseren van Linux.
Hierbij kan worden opgemerkt dat sinds kort op Linux-kernel-mailinglijsten een discussie is nieuw leven ingeblazen die zes jaar geleden werd gestart en gekscherend 1 april 2018 presenteerde.
En het is weer op tafel gelegd. de kwestie van “de haalbaarheid van het adopteren van moderne C++-code in de Linux-kernel”, die verder gaat dan het traditionele gebruik van de C-taal met assemblerfragmenten en de promotie van de Rust-taal.
Het oorspronkelijke voorstel werd in 2018 gelanceerd, door een Red Hat-ingenieur als een grap voor de bekende viering van de dwaas van april, waarin velen van de gelegenheid gebruik maken om grappen uit te halen over de gemeenschap en in die tijd was dat ook zo, aangezien het zogenaamd een set van 45 patches had uitgebracht die het gebruik van sjablonen, klasse-overerving en overbelasting van C++-functies.
Naar mijn mening is C++14 de “minimale” versie die redelijke ondersteuning voor metaprogrammering heeft en de meeste zonder de typen uit eerdere versies (C++11 had de meeste, maar C++14 vult enkele belangrijke ontbrekende stukken in). Naar mijn mening is C++20 echter echt de grootste gamechanger; Hoewel eerdere versies veel SFINAE-hacks konden uitvoeren, gaven ze ook absoluut nutteloze foutmeldingen.
We doen veel metaprogrammering in de Linux-kernel, geïmplementeerd met behulp van vaak vreselijke macrotrucs. Deze zijn ook vrijwel onmogelijk te debuggen. Laten we het voorbeeld nemen van hacks van het type uaccess.h, waarvan ik er enkele heb ontworpen en geschreven. In C++ kunnen verschillende casts en case-statements worden opgesplitst in afzonderlijke sjablooninstanties, en met een beetje vindingrijkheid kunnen zaken als userspace-pointers versus kernel-userspace-pointers ook strikt worden afgedwongen, evenals reeds gemarkeerde userspace-pointers, versus degenen die dat niet zijn. Om nog maar te zwijgen van de gemakkelijke afhandeling van 32-bits gebruikersruimtetypen in een 64-bits kernel en de toepassing van endian-conversie.
nu, bijna na 6 jaar hiervan, Hans Peter Anvin, een belangrijke Intel-kernelontwikkelaar en maker van projecten zoals syslinux, klibc en LANANA, heeft het initiatief genomen om de discussie voort te zetten. Volgens Anvin hebben de talen C en C++ sinds 1999 aanzienlijke vooruitgang geboekt in hun ontwikkeling, en is de taal C++ geschikter gebleken dan C voor de ontwikkeling van de kernel van besturingssystemen.
anvin vermeldt functies waarvoor voorheen specifieke extensies nodig waren van GCC, kan nu eenvoudig worden geïmplementeerd in standaard C++, en in veel gevallen zal het gebruik van C++ de infrastructuur verbeteren zonder dat de code volledig hoeft te worden gewijzigd.
Daarnaast Er wordt voorgesteld om minimaal de C++ 14-specificatie te gebruiken, dat onder meer metaprogrammeringstools omvat, en het gebruik van de C++ 20-specificatie wordt aangemoedigd, die ondersteuning introduceert voor concepten die de incidentie van fouten kunnen verminderen.
Er wordt beweerd dat C++ meer de voorkeur heeft dan Rust, aangezien de laatste qua syntaxis aanzienlijk verschilt van de C-taal, is dit ongebruikelijk voor de huidige kernelontwikkelaars en staat het geleidelijk herschrijven van code niet toe. In het geval van de C++-taal is het mogelijk om delen van de C-taalcode geleidelijk te vertalen, vergelijkbaar met hoe C-code kan worden gecompileerd als C++.
Hoewel de Linux-kernel voornamelijk uit C-code bestaat, met verschillende onderdelen die in assemblage zijn geschreven en er steeds meer werk wordt gedaan rond Rust-ondersteuning in de Linux-kernel, is het nog steeds onduidelijk of er voldoende gewicht is om dit werkelijkheid te laten worden, over de mogelijkheid om de C-code van de Linux-kernel te zien in de toekomst omgezet naar C++.
eindelijk als je bent geïnteresseerd om er meer over te wetenkunt u de details in het volgende link.