C++ och dess framtid att programmera minnessäkert - Hur går utvecklingen?

Du fokuserar jättemärkliga saker och jag kommer anta att du syftar på API endpoints som hanteras av webbservern. Olika typer av API-designer har olika mängd endpoints. Vissa API-designer typ REST använder endpoints flitigt eftersom endpoints mappas till resurser(typ objekt eller tabeller eller dokument beroende på backend och syfte). Att reducera mängden endpoints betyder enbart att API-designen ändrats så att motsvarande information om resurstyp förmedlas på annat sätt, det säger inget om läget blivit bättre eller sämre. Enda gången detta är tydligt bättre är om man upptäckt att en eller flera resurser är redundanta och man kan simplifiera API-designen genom att ta bort dom men det är ju bara som ett resultat av att man haft suboptimal API-design inledningsvis...

Exempelvis om man byter till JSON RPC så behöver du enbart en endpoint men då ligger resurstypen i JSON-objektet istället, dvs inte nödvändigtvis bättre enbart annorlunda. Samma komplexitet måste istället hanteras i parsningen av JSON-objektet istället för HTTP-requesten.

Detta låter jättemärkligt, vad menar du med att inte veta när dom körs? Din webbserver vet ju när den redirectar requesten alternativt så kommer underliggande kod(API-implementationen) vet ju när den anropas. :S

Alla språk tolkas mha parser men jag misstänker att du försöker säga något annat som du missat att skriva.

Vad för kod skrivs inte i Python?

Här är matrix(kommunikationsprotokoll) API specification med åtminstone 110 endpoints:
https://github.com/matrix-org/matrix-spec/tree/main/data/api

Här är server-(referens)implementationen av protokollet, i Python:
https://github.com/element-hq/synapse

115 miljoner användare enl. https://www.thestack.technology/matrix-protocol-users-2023

Vad är det du typiskt utvecklar? D.v.s. hur komplicerad är domänen och vad är implikationen när det går fel?

Skulle säga att när man jobber med väldigt komplexa problem är det kritiskt att bryta ned delarna så de blir relativt enkla. Annars lär man aldrig få ihop något som fungerar.

Är när man jobbar med relativt enkla problem man kan kosta på sig att göra lite mer fancy lösningar som i sig kan vara lite mer komplex.

Låter som du jobbat i organisationer med rätt kass styrning. Men rätt strategi kan man få god utväxling även med rätt juniora utvecklare i komplexa projekt med väldigt stora kodbaser.

Angående Java: (jobbade med Java på Windows runt 2000) det fanns en licens att följa för 3:e-parts JVM:er, Microsoft misslyckads med det, blev stämda och tror de själva fattade att de inte var bättre än någon annan att bygga JVM:er. De tog istället .NET spåret där det kunde pusha Windows specifika tekniker utan att hamna i rätten.

Givet att Linux dominerar i stort sätt allt förutom desktop, inklusive flertalet områden Microsoft försökt pushat Windows och misslyckas kapitalt då det är tekniskt underlägset Linux i de områdena, så är det rätt naturligt att flödet mer än Linux -> Windows sedan rätt långt tillbaka.

WSL2 var i.o.f.s. ett genidrag av MS. Fixar inte att arbeta utan *NIX system, för mig har WSL2 gjort Windows användbart igen!

Är inte alls med på vad du ser som så bra med Windows. De dominerar PC-spel och desktop, båda egentligen på gamla meriter. Kollar man OS/system-nivå funktioner innehåller Windows väldigt många WTF?! medan både Linux och MacOS långt oftare tänkt till före.

Det är relaterat till din annekdot om 100 endpoints och din citering av @Ingetledigtnamn som beskrev återanvändning av kod där du sedan hävdade att det inte går. Jag har svårt att veta vad du verkligen menar eftersom ditt inlägg var lite vagt i det avseendet. Synapse har både interna och externa moduler som tyder på återanvändning av kod samt att dom har 100+ endpoints. Dom gör inte massa magi i webservern utan använder den som en reverse proxy och verkar inte ha några problem med sin design.

Detta är nonsens. UTF-8 (Unicode Transformation Format 8-bit) är som namnet antyder en del av Unicode.

Windows körde under lång tid på Windows 1252 (en utökning av ISO-8859-1, även känd som Latin-1) som teckenkodning. Detta lever till viss del kvar än idag i vissa program. Om det haft någon signifikant inverkan på att den saliga röra till OS som Windows är kan jag dock inte uttala mig om.

Edit: Windows Code Page heter legacy-teckenkodningssystemet, där page 1252 är teckenkodningen som används för de flesta västerländska språk.

Så när du säger att "återanvända kod", vad syftar du på då? I min bok kan detta vara allt ifrån macros, generics, templates, interface, moduler, externa lib:ar osv. Allt detta är exempel på kod som är skriven en gång och kan återanvändas.

När du säger att "återanvända kod" så är det svårt iaf för mig att veta exakt vad du syftar på och då kommer jag falla tillbaka på vad jag vet sedan tidigare och om Python-koden ifråga använder en eller flera av sakerna ovan så kommer jag tolka det som att Python-koden är kapabel till att återanvända kod och invalidera ditt påstående.

I detta fallet så vet jag inte heller vad du menar med "samma" kod. I min bok så är det samma kod om checksumman på källkodsfilerna.

En bra förklaring finns här och jag tolkar det som att, om jag av en olycklig händelse skulle skriva mitt första Windows-program, så skulle jag inte behöva bry mig om namnen ovan alls. För att använda dessa så används macrona CreateFile(), CreateProcess() etc och korrekt variant bestämms av systemets konfiguration, oklart om det är runtime eller compile-time.
https://stackoverflow.com/questions/51462048/what-is-the-diff...

För övrigt har jag kväljningar redan.. Använder man verkligen CreateFile() för att LÄSA en fil i Windows ????
https://learn.microsoft.com/en-us/windows/win32/fileio/openin...

hFile = CreateFile(argv[1],     // file to open
            GENERIC_READ,       // open for reading
            FILE_SHARE_READ,    // share for reading
            NULL,               // default security
            OPEN_EXISTING,      // existing file only

OK, den här meningen kanske förklarar orsaken..
https://learn.microsoft.com/en-us/windows/win32/api/winbase/n...

Som du säger, vilken sörja! Då jag reagerar ganska starkt på sådana här dumheter så känner jag att mitt liv har varit väldigt förnöjt då jag flera gånger tackat nej till Windows-programmeringsuppdrag.

Har inte du blandat ihop DOD med DDD (Data Driven Design)?

För ser inte att du har fokus på hur data är organiserat i minne, eller lägger du saker i SOA-ordning för lättare hantering m.h.a. SIMD?

Sen konkrent, vad har de saker du gör för implikation när det går fel?

Egna exempel är kod som skickats till Mars, hyfsat svårt att skicka en service-tekniker om det strular. Kod som sitter på platser där en bug kan orsaka fysisk skada i form av att potentiellt orsaka brand (BMS-styrsystem) eller ta livet av folk (styrsystem för flygplan). Kod som vid fler orsakar extrema kostnader, som nätverkslösningen i ASML-scanners där en bug lär paja pågående "wafer" (en sådan kostar idag 20k-30k USD styck) och ännu värre om det stoppar produktion (~2000 wafer per dag).

Alla ovan exempel är också exempel på varför det tråden egentligen handlar om är högst kritiskt. Så länge som man skriver i C eller i C++ (alla exempel ovan är skrivna i C utom BMS som är i Go) och man inte fixar de problem andra har löst relaterade till minnessäkerhet så ser vi gång på gång att i C och C++ är >50 % av buggarna relaterade till minnesproblem. Buggar som i stort sett inte existerar i minnes-säkra språk!

Alla moderna språk/ramverk jag känner till har inbyggt stöd för Unicode. Nog rätt svårt att få in riktigt bra C/C++ stöd i efterhand tyvärr, så där kommer det fortsätta vara drygt att hantera...

Så tabben var inte att gå till Unicode, tabben var att basera hela "moderna" Win32 APIet på UTF-16 och inte UTF-8.

Även i C# där stränghantering är "helt byggt för att vara native med modern Win32" har redan vissa problem p.g.a. av valet av UTF-16 och hur det medförde att "Char" rimligen då är ett 16-bit tal: inget bra stöd för code-points >65535...

Tror nog de som jobbar med filhantering, web etc nog stött på problem med hantering av BOM p.g.a. Microsoft val att gå UTF-16 native och resten av världen i praktiken valt UTF-8. UTF-8 BOM "EF BB BF", UTF-16 (little-endian) BOM "FF FE".

Behöver själv göra en "refresher" kring hur allt detta hänger ihop rätt ofta. Vill bara att text-hantering ska fungera, men det är rätt komplext...

Unicode är en standard som säger vad varje tal (code-point) ska representera. Det är valt så 0-127 är samma som ASCII.

UTF-8, UTF-16 och UTF-32 är olika sätt att representera code-points på disk/RAM etc. UTF-8 har den stora fördelen att det blir identiskt med ASCII om man bara använder code-points <128.

Så här i efterhand hade det kanske varit bäst att utelämna UTF-16 helt... UTF-32 används rätt sällan, men finns ett värde. T.ex. löser Go-lang det problem C# har med code point >65535 genom att "Rune" (i praktiken det närmaste man kommer C# Char) använder UTF-32. I alla lägen där man representerar en sekvens av code points (t.ex. strängar) används UTF-8.

FooBarA → Den äldre varianten som bara stödjer 8-bitars tecken. En av Windows stora styrkor är dess mycket goda bakåtkompatibilitet, och därför finns det fortfarande mycket kod som saknar Unicode-stöd, särskilt sådan som är skriven i C och C++.

FooBarW → Unicode-varianten som använder UTF-16 i little-endian-format.

Vilken variant som används avgörs vid kompilering. Om man råkar blanda ihop dem kan det leda till ganska förvirrande länkfel, särskilt om man inte är bekant med denna uppdelning.

Möjligen? Om inte STL och Boost är återanvändning, vad har du för definition av återanvändning? Är det bara genererad kod som räknas? I C++ torde templates tävla med funktioner om att vara den av de mest utbredda formen av "skriv en gång, använd i flera sammanhang". Funktionen är ju den mest grundläggande formen av återanvändning, men templates används ju till allting i C++. Frågan är om inte ett modern C++-program instansierar mer template-kod än användaren har skrivit själv.

Det du föraktfullt kallar bloat används ganska ofta för att optimera C++-kod. Genom att använda template specialization istället för virtuella funktioner ges kompilatorn helt andra möjligheter till inlining och optimeringar över funktionsanropsbarriären. Visst, det blir mer kod, men det är en balansgång mellan prestanda och kodstorlek där man själv får bestämma vad som är viktigt.

"Generell" och "skrivs för att fungera i så många sammanhang som möjligt" signalerar för mig att koden kommer göra många olika saker och det kommer vara svårt att få bra coverage med enbart systemtester. Är inte detta ett typexempel på kod som skulle må bra av enhetstester?

För någon som är så hemma i datadriven design borde det ju knappast vara några problem alls!

UTF-8 är self-synchronizing (vilket även gäller UTF-16), så går hitta punkten där två strängar skiljer sig genom memcmp()-lik funktionalitet och sedan backa till början av innevarande code-point.

Sen är det bara extrahera varje code-point som 32-bit och jämföra -> det avgör lexikografisk ordning.

Och bara för det tagit till Ragnarök i C++ betyder inte att folk redan löst problemet. Java/C# har sedan start hanterat strängar som sekvenser av UTF-16 och Go-lang har hanterat strängar som UTF-8 sedan första release.

Givet vad denna tråd egentligen handlar om och givet trenderna tror jag extremt få skulle välja C++ för ett green-field projekt idag. Det lär man bara göra för man helt enkelt inte kan något bättre. C++ finns (och kommer fortsätta finnas under överskådlig tid) nästan uteslutande för man jobbar med brown-field alt. måste använda brown-field bibliotek som bara fungerar med C++.

Förut fanns ändå ett värde med C++ direkt vansinniga komplexitet. Inget annat matchade prestandan. Men beroende på vad man gör är inte längre C++ det bäst presterande alternativet. T.ex. finns flera smarta optimeringar i multicore-programmering som inte blir korrekt utan GC (sure, man kan implementera en GC även i C och C++, faktum är att Linux-kernel använder den här typen av optimeringar på vissa ställen och har då "tillräckligt mycket av en GC" för att få det att fungera).

Du har du helt missförstått vad jag anser är komplex i C++. Det är språket som allt för komplext, något som bl.a. manifestera sig i vad som lär vara den lägsta specifikation av alla relevanta programspråk just nu.

Det syns också i de löjligt långa kompileringstider, något som gör det allt mer tveksamt att välja C++ för riktigt stora projekt (Go utvecklades av 3st C++ programmerare som också råkade ha tidigare erfarenhet av språkdesign, enligt ryktet gjordes första draft:en "medan vi väntade på att ett av Googles C++-projekt skulle kompilera om").

C är inte komplex, efter C++ lär nog C# vara #2 (sett till hur omfattande specifikationen är). Så Microsoft lyckades verkligen göra C# till "ett modernt C++" ur den aspekten...

Inget av ovan är speciellt relevant i att bygga en effektiv hantering av UTF-strängar. Igen vettig människa använder C frivilligt i saker som kräver stora mängder stränghantering, C har inte en bra design för just detta. C++ är bättre än C här, men ändå långt sämre än andra "moderna" språk så av den anledningen lär UTF-8 hantering inte varit #1 för C++ världen.

Visst är det en utmaning om man av någon outgrundlig anledning måste skriva en egen implementation från scratch.

Men varför skulle man göra det med någon annan anledning är "vill lära mig detaljerna som ett kul projekt"? Det är ett i stort sett löst problem med otroligt smarta optimeringar för att validera att en byte-sekvens är giltig UTF-8, för jämförelser etc. Använd det så är det inte svårt!

Väldigt många gör saker i Python som antagligen är långt över huvudet på alla oss i den här tråden, inte minst inom machine-learning. Så det behöver inte vara så "himla lätt" bara för att det är Python, det är inte nödvändigtvis ens lätt att använda de färdiga biblioteken för men rätt kunskaper om algoritmer och avancerad matematik kan man addera väldigt komplexa saker ovanpå.

Men finns också saker som går hur bra som helst att använda utan att förstå. Kan matematiken bakom 3D väldigt väl, ändå känns det rätt onödigt att veta hur ett bra bibliotek fungerar mer än "de har gjort optimeringar lämpliga för moderna CPUer". Och likt UTF-8, varför skriva själv när det redan finns flera alternativ där man redan putsat effektiviteten rejält?

Exakt. Med rätt abstraktioner kan "vem som helst" utnyttja expertisen från andra och man kan då hålla fokus på det problem man själv ämnar lösa. Ett problem som i sig kan vara rätt komplext, då kritiskt att kunna slippa gräva ned sig i andra komplexa saker samtidigt.

Eller "nu har jag lärt mig pre-C+11 och hur man optimerar för CPUer pre-very-wide-OoO-eran", så nu är jag fullärt och alla som inte fattar det jag fattar är n00b:s. Världen har en tendens att gå vidare, gamla sanningen är inte längre nödvändigtvis sanna längre!

Och en annan helt ad-hoc definition är "om koden inte används i saker som omsätter >1 miljard USD per år har det rätt lite med programmering att göra".

Din definition av programmering är lika meningslös som den jag hittade på ovan, acceptera att vad som är programmering innefattar definitivt all for av kodskrivande oavsett språk. Sen kan man eventuellt diskutera om "HTML-knackande" även är programmering.

Beror på vad du anser är "nytt". DOD som koncept daterar tillbaka till strax efter millennieskiftet.

Det är inte bara det. På 80-talet skrev väldigt mycket av spel i assembler. Inte bara för det var snabbt, utan för att dåtiden kompilator-teknik var inte alls på samma nivå som idag.

Idag går det inte cykel-räkna samtidigt som moderna kompilatorer (inte minst de som som kan JIT:a) kan göra optimeringar som är helt orimliga att få ut ur en människa inom någon form av rimlig tid.

Väldigt nära 100 % av tiden, givet ett inte helt trivialt problem, lär bättre prestanda (om det behövs) komma ur saker som bättre algoritmer eller min egen favorit: lura ut sätt som gör att man överhuvudtaget inte behöver göra beräkningen, och om den måste göras görs den långt mer sällan.

OK, ge ett konkret exempel på hur du använder SOA i din kod. Är inte det lite utmanande när du samtidigt verkar gilla variants (antar att du kallar det "ha flexibilitet i datatformat"...).

Båda. Har tidsmässig i arbetslivet mest erfarenhet av RTOS-världen. Det som skiljer hård-realtid från "vanliga" program är att ett korrekt svar som kommer efter den dead-line som krävs är lika mycket en bug som ett felaktigt svar.

Men för denna diskussion: håll dig till "det blir fel svar / smäller".

OK, så använd något mer modernt / bättre anpassat för uppgiften?

I Go är inte strängar bara UTF-8, de tar 16 bytes på 64-bit arkitekturer och 8 bytes på 32-bit arkitekturer (den senare är i praktiken bara relevant för MCUer idag, men Go används där också)

I Rust är string-slices (&str) 16/8 bytes på 64/32-bit medan mutable strängar (String) är 24/12 bytes. I de flesta fall jobbar man där med &str utom när man bygger strängarna. Här hålls också strängarna i UTF-8 format.

Edit: fast vad gör man för att det ska vara relevant??? Man måste i det läget göra extremt trivial datahantering av extremt många ytterst korta strängar. För annars kommer man ha andra viktigare flaskhalsar!!!

Även om de lägsta nivåerna av t.ex. Pytorch och NumPy är skrivna i C/C++ är det långt mer än "konfigurering" som sker i Python-kod när man jobbar med modern ML-teknik.

Så just den delen är bara en implementations-detalj.