Skrivet av medbor:
Sanningen är att de allra flesta projekt består av många tusen rader kod i flertalet moduler. Har man tur så är varje modul hyfsat konsistent, men oftast har man årtionden av legacy. Vissa utvecklare brinner för att använda allt det senaste, då blir det vanligt med en hel del templating från de år där det var det bästa som fanns, sen kommer åren av auto återspeglas på andra delar. Vissa delar kanske kör med compiler hints för att optimera prestandan och programfilen ännu mer
Sanningen är att det helt beror på vilket projekt du sitter i för stunden, och allt ändras över tid baserat på hur du och dina kollegor utvecklas
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.
Skrivet av orp:
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.
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å.
Skrivet av heretic16:
Att du minns vad jag har skrivit..... Kanske bara jag som har skrivit dessa frågor?
Jag har hört att Rust är bra, verkligen bra men kan inte verifiera om det är värt att kunna rust då det inte tillämpas på inbygga system, men jag ogillar den komplexa syntaxen.
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