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

Att kunna vedertagna termer och definitioner handlar om att vi vill beskriva saker på ett mer kompakt sätt och om du inte kan dessa så var ärligt och säg "Sorry, jag kan inte detta".

Varför är somliga termer och definitioner ok enl. dig som templates, namespaces osv men inte andra?

Att ha en introvert personligheter innebär ofta att man är mer tillbakadragen i sociala sammanhang inte att man är dåligt påläst. Dvs introverta personer kan ofta termer och definitioner men hoppar ogärna in i diskussioner för att hävda det.

Nu trollar du igen...

Python är ett programmeringsspråk så om du skriver Python så per definition så programmerar du.

Annars kan vi inte klassa C++ som programmering i heller det är enbart ett par stödhjul till C. C++ är ju enbart en verktygslåda för folk som är för dåliga för att koda C...

Jag tror att du trollar eftersom det du skriver nedan brukar folk avgöra med lite abstrakt tänkande...

Om det finns undantag så _bör_ du inte generalisera.

Alla hårdkodar oavsett programmeringsspråk. I min editor just nu så har jag en hårdkodad sträng i C för en socket-path, kan du gissa varför?

Där är mängder av saker man gör i C++ som man inte gör i C, så därför kan vi inte klassa C++ som programmering?

Jag tar några axplock.

Här säger du att Go är värdelöst:

Hävdar ogrundat att prefetching skulle fungera sämre i Go. Att man skulle få mer fragmentering, vilket är helt fel eftersom ett språk med GC faktiskt kan packa om saker på heapen. Och att man inte skulle kunna "trixa med bytsen" tror jag inte heller på.

När jag borrar lite djupare i detta ämne får jag veta andra språk utnyttjar cache, prefetching och SIMD sämre:

Rent nys.

Långsiktighet och skalning är inte viktigt i Python. Språket är inte gjort för det:

Det är en massa optimering som kompilatorn inte kan göra om språket har GC:

När jag fråga om vilka optimeringar man inte kunde göra för att språket körde GC kom ett exempel med C++ mot Rust!
C++-kompilatorn kunde minsann generera SIMD-kod. Även om du inte uttalat skriver att Rust-kompilatorn inte kan generera SIMD, så är det underförstått i en A mot B-jämförelse. Om både A och B kan göra något är det ju missvisande att lista det för bara den ena.

Jo, Rust kan också generera SIMD-kod.

Om du istället för att droppa random teknisk term och tillskriva det till C++ faktiskt höll dig till det du vet är sant (och kan backa upp med källor) skulle du få mycket mindre mothugg.

Nej, det är inte enbart du och jag som tänker olika om programmering. Du och resten av världen tänker olika om innebörden av programmering. Enl. din egen definition för programmering så kan det inte ens tolkas som svenska.

Från SOAL(svenska.se):

Från SO(svenska.se):

Jag är övertygad om att Python uppfyller dessa kriterier och därför klassas som programmering.

Jag tror det är bortkastad tid att försöka överbevisa något för dig eftersom du trollar och ignorerar alla bevis som presenteras.

Nu hittar du enbart på nya saker. Du kan börja med att besvara tidigare frågor innan jag lägger tid på att förklara saker för dig.

All kod i språk som man inte behärskar ser ju bedrövlig ut.

Det här håller jag med om, jag har t.ex. tidigare bett dig berätta om något du faktiskt har gjort, det skulle vara ett bra sätt för oss att kunna verifiera att du är den överlägsna programmeraren du påstår dig vara.

Och nu senast så bad någon dig om din definition på "state".

När jag säger att "du hittar på" så anser jag inte att din påhittade utmaning är omöjlig utan att det är ett korkat sidospår istället för att avsluta alla andra sidospår du dragit igång.

Om du skriver samma sak i C++ blir koden helt plötsligt smidig att jobba med? Skall vi jämföra äpplen och äpplen förväntar jag mig att ditt interface mot blocket presenterar strängarna som std::string.

Varför är det inte OK att Java gör saker under ytan?
Varför är det OK att C++ gör saker under ytan?

Varför är det OK att C++ kommer med gigantiska bibliotek?

Du har redan fått konkret exempel på fall där samma imperativa logik blir väldigt mycket snabbare med en GC jämfört med C++, kanske på plats med sanna konkreta exempel på varför GC är så mycket långsammare? (Och, nej din video duger inte då arena-allokator är absolut inte unikt för C++ utan går med fördel att göra även om man har en GC)

Får väl tillstå att jag helst slipper koda i Java. Men går inte att komma ifrån att det vi fick höra under senare delen av 90-talet om att "JIT-kod kan vara precis lika snabb som kompilerad C/C++, eller i vissa fall till och med snabbare" kanske kändes som ett skämt de första 10-20 åren efter Javas intåg på marknaden.

Idag är det en realitet, ignorerat "JIT-warmup" så är presterar de mest optimerande JVM:miljöerna otroligt bra och de används absolut i en del väldigt prestandakrävande miljöer.

Några exempel där Java används bl.a.

LMAX Disruptor: A low-latency messaging library developed for a trading platform; Java-based and famous for its performance.

Sedan finns "big-data" ramverken Kafka, Hadoop och Spark som alla körs på JVM (skrivna i Java och Scala).

Vad det gäller Go är som sagt inte dess styrka "compute-bound". Men med mindre än att du också överger väldigt grundläggande funktioner som libc och det som ligger direkt ovanpå i C++ standardbibliotek så är det rejält svårt att matcha I/O-prestandan man hyfsat lätt når i Go från C++ (framförallt i Linux där Go använder io-ring och liknande "by default").

Vad är det det specifika problemet i andra språk?

Go har pekare, men inte pekar-aritmitik. Vad är det som är krångligt i det exempel som Ingetledigtnamn gav dig i Go ovan, ser väl väldigt "enkelt" ut och är framförallt ingen extra kopiering av data eller liknande. Gör man en minimal förändring går det också enkelt att iterera över sina "packade" strängar (fortfarande utan kopiering).

func (ps PackedStrings) Get(index int) (string, bool) {
	if index < 0 || index >= len(ps.offsets)-1 {
		return "", false
	}
	return string(ps.data[ps.offsets[index]:ps.offsets[index+1]]), true
}

func (ps PackedStrings) Iter() iter.Seq[string] {
	return func(yield func(string) bool) {
		for i := 0; ; i++ {
			if s, ok := ps.Get(i); !ok || !yield(s) {
				return
			}
		}
	}
}

...

	// Can then iterate like this over the packed strings, zero-copy
	for s := range ps.Iter() {
		fmt.Println(s)
	}

Att kunna casta saker i princip hur som helst har sina användningsområden, men det är ändå en av sakerna som lite kommit att bita C och C++ i arslet för idag kan det hindra kompilator från att göra vissa optimeringar som är möjliga i andra språk som Rust, Go, C#, Java m.fl.

Att inte kunna garantera att en viss minnesadress är typ-stabil under sin livslängd hindrar också vissa multicore-optimeringar. I.e. det är C och C++ som börjar uppvisa vissa ålderdomssymtom här då HW-design har ändrats!

Vi har pratat om det här förut. Ur språkstandardens synvinkel är det bara effekterna synliga i den virtuella maskinen som beskrivs. Finns de där är det en tillåten översättning.

Kompilatorn gör saker under ytan hela tiden. Det anropas destruktorer. Det görs en massa hemskheter under ytan när du har virtuella baser och ett objekt skall ses om en av dess virtuella baser.

Hur påverkas din bild av att inget får göras under ytan när man slår på optimering? Loop invariant code motion flyttar exempelvis ut kod ur en loop. Koden som lyfts ut är inget du har bett om att det skall evalueras före loopen. Common sub expression kan flytta kod långt. Det är också kod som kommer evalueras på ett ställe där du inte har bett om det.