Varför har inte C några C++ funktionaliteter?

För att svara titeln: För att det är C.
Alla som vill ha C fast mer, typ C = C+1, ja du kan gissa vart dom hamnar.
Vi klurade ut det för typ 30 år sen.

C är gammalt och många gillar C som det är och vill inte ha mängder med oanvänd funktionalitet. Min uppfattning är att det gör språket mer svårportat och att många anser inte att funktionaliteten är kritisk. Varför tycker du att det ska vara en del av standard lib:et istället för ett separat lib typ ELL eller Glib?

Detta är tredje eller fjärde tråden som du skriver där du inleder med att du kodat C länge och du beklagar dig över dess funktionalitet, kanske dags att se dig om? Jag kan tipsa om Rust.

Jag jobbar som senior c++-utvecklare och kan konstatera att c++-utvecklare kommer i många former och färger. Vissa skriver i princip C, vissa skriver allt i templates, och vissa håller sig på lagom nivå och anpassar sig efter vad som är lämpligt i teamet man jobbar i - dvs oftast objektorienterat, med smartpekare, sparsamt med auto, och inte alltför mycket c++20-nymodigheter.
Templateprogrammerarna är hemska att ha att göra med. C-programmerarna är ok, deras kod går åtminstone att läsa.
Om du "lyxprogrammerar" för personligt bruk så gör du givetvis på det sätt du trivs bäst med.

Det markerade: vissa försöker vara smartare än kompilatorn. Initialt kanske det, ibland, faktiskt fungerar. Ett hyfsat välkänt projekt, Linux-kärnan, hade en del sådant. Linus testade att rensa bort allt sådant och i alla fall han testade så var det snabbare utan dessa "hints".

Dagens kompilatorer är i de flesta fall så pass kompetenta och avancerade att de gör ett bättre jobb än en förkrossande majoritet av mänskliga programmerare när det kommer till den här typen av optimeringar.

Undantag finns naturligtvis alltid. Men just denna typ av optimering fungerande bättre förr när kompilatorer var sämre och CPUer saknade väldigt djup out-of-order körning. Idag kan optimeringar som känns logiska för en människa har motsatt effekt då man designat CPUer för att hantera typfallen.

Det finns en väldigt bra anledning varför C fortfarande är väldigt populärt, framförallt till systemprogrammering på lägre nivå samt kernel-utveckling.

C är datorvärldens lingua franca. Om ett programspråk/plattform har någon form av stöd för att kommunicera med andra språk/plattformar går det nästan uteslutande via C ABI.

C++ har haft problem i dessa område bl.a. p.g.a av att Bjarne explicit valde att inte definiera C++ på binärnivå.

Rust har ett jätteproblem: det är en rätt ordentlig tröskel man måste ta sig över för att vara någorlunda produktiv i det språket. Betydligt större än andra populära språk (avancerad template-meta programmering i C++ undantaget, det måste ta något form av pris i komplexitet...).

Rust har massor med fördelar, en av de absolut största fördelarna hänger rätt tätt ihop med varför det blir en rätt stor tröskel att lära sig språket. Rust tillåter bara kodkonstruktioner som kompilatorn kan bevisa är korrekta ur minnessäkerhetsynpunkt (både inom en tråd, och vad som är helcoolt, mellan CPU-trådar). En bieffekt av detta är att vissa fall som är korrekta, i alla fall i det speciella kontext man tänkt sig, misslyckas att kompilera då de medger de svar/garantier som behövs för att upprätthålla allt det man garanteras inom ramen för Rust.

Om man inte använder "unsafe Rust" så är man garanterad att en program som kompilerar saknar "data-race" (absolut värsta typen av buggar i multitrådade program), det finns inga "null-pointer" referenser (personen som införde "null" i Agol 1965, Tony Hoare, har kallat det sitt "The Billion Dollar Mistake" givet hur mycket problem det ställt till med), m.m.

Prestandamässigt är Rust helt i nivå med C och C++. Skriver man någorlunda idiomatisk kod av respektive språk är i praktiken C++ och Rust i flera fall lite snabbare än C. Orsaken är att kompilatorn har mer kontext kring vad man faktiskt försöker göra i de två förra språket (men självklart kan man "hand-jaga" C-koden till att vara lika snabb, men det kan vara rätt drygt).

Finns några nischer där Rust-kompilatorer kan göra optimeringar kompilatorn inte kan göra i C/C++ inom ramen av standarden (men finns typisk kompilatorflaggor för att säga: "skit i standarden, jag vet vad jag gör", så får man tillbaka de enstaka procenten).

Sen vet jag inte vad du definierar som "inbyggda system". Världens största realtids OS, VxWorks, har officiellt Rust stöd (för applikationer) sedan 2019 (var en av arkitekterna som pushade hårt för att få in Rust i produkten). Vidare lär Linux med råge vara världens populäraste "embedded OS" idag, där används ju Rust numera även i kärnan och stödet för applikationer är ju lysande då Linux, Windows och MacOS är de OS Rust-team:et ser som "primära".

Angående den ursprungliga frågan kring varför C och C++ inte har så mycket inbyggda funktioner finns tre primära svar:

1. de är gamla, när dessa språk skapades lade man typiskt inte till gigantiska standardbibliotek som vi ser hos Python, Java, .NET, m.fl.
2. båda är primärt designade som "systemspråk". Enda moderna systemspråket vi sett med någon större framgång är Rust. Just då Rust designats för att vara systemspråk har man likt C++ standardbibliotek fokuserat på väldigt generella funktioner med mycket brett användningsområde. Resultatet är ett relativt litet standardbibliotek
3. associerat med 2., för att kunna använda standardfunktionerna i alla typer av system språken kan tänkas användas till blir det flertalet saker som inte har någon relevans i standardbiblioteket. T.ex. grafik, ljud etc då det inte ens är relevant på vissa inbyggda system och definitivt inte på en typisk mikrokontroller

Fast den typen av system har i praktiken bara ett kodsegment där du kan stoppa in vad som helst bara det kan prata via C ABI.

Rust har explicit stöd för att kommunicera med C + att det finns en väldefinierad delmängd av Rust som specifikt inte beror av någon OS-runtime. D.v.s. det finns allt stöd man kan tänka sig för mikrokontrollers.

Rust är inte populärt inom mikrokontroller än, men stödet finns där redan idag och det mesta är beskrivet i Rust Embedded book som nämns i tråden.

VxWorks må sakna officiellt Rust stöd i kärnan, men med informationen i Rust Embedded book var det inga större svårigheter att använda Rust i dess kärna redan innan officiella stödet lades till. Har sett folk använda Rust ihop med FreeRTOS, bl.a. på ESP32/ESP8266 (som normalt kör Arduino, d.v.s. definitivt mikrokontrollers)

Tror ingen förväntar sig att Rust ersätter C eller C++. Är väl egentligen inget av de programspråk som i något läge varit riktigt populärt som blir ersatt, de har bara minskat i popularitet.

C lär stanna, just då det är den "standard" som i praktiken alla andra språk använder som brygga mot omvärlden^*

Samma sak gäller C++. Väldigt mycket av den infrastruktur vi beror av dagligen använder enorma mängder C++ kod, ytterst få av dessa bjässar kommer skrivas om i något annat språk.

Men till och med C++ världen får erkänna att om man startar från scratch finns få anledningar att använda C++ över Rust om det senare har de bibliotek man behöver.

Rust och Carbon siktar på två väldigt olika mål. Min gissning är att Rust kommer (skulle säga att den redan har) hitta sina nischer, betydligt mer tveksamt att Carbon gör det.

Rust försöker göra det bästa tänkbara programspråket för systemprogrammering, utan att begränsas av något tidigare bagage.

Carbon huvuddesignmål är att ge "bi-directional C++ interop" (d.v.s. ska vara möjligt att anropa all C++ från Carbon och även anropa Carbon från C++). I de senare C++ standard versionerna har man bl.a. sneglat på vad Rust gjort rätt och man har infört de delar som kan införas utan att paja bakåtkompatibiliteten.

Carbon tar det ett steg längre, här tillåter man sig rätta "gamla" misstag så läge som man kan göra det inom ramen av C++<->Carbon kompatibilitet. En sak man därför inte kan erbjuda i Carbon är de garantier Rust kan göra kring data-race säkerhet.

Så Carbon är tänkt som "ett bättre C++" i fall där man redan är fast med C++. Fråga är om fördelarna är tillräckligt stora för att ska få någon fart. Rust är tänkt som "det bästa systemprogramspråk vi i nuläget är kapabla att skapa", det utan att tänka på C++ (men man har explicit tänkt på C interop, fast det hamnar inom "unsafe rust" ramen).

^* Inte helt sant, Go är ett spännande undantag där man inte alls använder libc eller motsvarande under huven för att prata med OS:et utan där går man alltid direkt på systemanropen som ligger en nivå lägre. Man har explicit stöd för att anropa C, men det är rätt ineffektivt och ska aldrig användas i någon "critical path".