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

Steppa bakåt har jag inte varit med om, men det går att "köra om" kod och det behöver man inte enterprise för att göra.

Menar inte att dessa IT jättar är kassa rätt igenom, de gör självklart bra saker om de tjänar på det.

Men det är aktiebolag och ägare kräver avkastning samt att ägarstrukturen till de största IT bolagen är samma, samma ägare hos alla. Hela systemet är kontrollerat. Det här blockerar massor av möjligheter.

Om Apple velat hade de kunnat haft mycket mer funktionalitet i vad de säljer men de hade inte tjänat på det. Vad Apple (Microsoft, Google mm) gör är saker för att låsa kunden.
Tror också att denna kritik som plötsligt dök upp om minnesproblem i C++ lobbats för eftersom det kommer från amerikanska underrättelsetjänster. De agerar proaktivt för de kommer få jobba om sina modeller med AI, en teknik de troligen inte kan kontrollera.

Att exempelvis Google haft över 90% av sökmarknaden är rubbat.

Håller med och Linux är byggt mycket efter hur Linus "tänker". Men jag tror det varit nyttigt för linux för hans kritik mot C++ behöver inte vara fel. Bra kod i C++ ställer mycket höga på utvecklare och C++, alldeles för lätt att skriva C++ kod som även om den skulle vara bra är helt omöjlig att förstå för andra.
Exempel på sådan kod är sol2. Fantastisk kod men räkna inte med att någon annan utvecklare kommer ta över koden.

Håller med. Mycket kod kommer dö med utvecklaren som ligger bakom. Att få stöd hos andra är så mycket svårare än vad många förstår. Enda realistiska möjligheten som jag ser det är att företag som tjänar pengar på produkten också får del av koden och kan börja underhålla den, då gärna flera.

Och den typen av kod som kan leva så länge är i princip 100% utvecklad i C eller möjligen C++, bra om det dyker upp alternativ men det kommer fortsätta domineras av C eller C++

Jag försökte precis förklara det, det är inget i den koden som är unikt för C++ men utvecklare i andra språk skriver inte sådant. Det är mycket ovanligt och jag förklarade varför

Det går säkert att göra detta på en hel hög med olika sätt. Problemet jag nu hade var att jag inte hittade en enda lösning på det här. INGEN.
Du får nog förklara mer vad som skulle vara "enklare"? Inte säker på att jag är hundra på vad du menar även om jag anar

Jag ville i alla fall ha något enkelt för att lätt kunna radera eller lägga till om filen behöver expanderas eller rensas.

Och om det skulle behövas komprimering är det ett senare projekt. Har inte tid att sitta med denna lösning allt för länge.

För att följa fasta mönster. Skickar jag något med referens så blir det alltid const. string_view som är speciell får samma behandling.

Och jag tvivlar på att koden i slutändan kommer skilja sig, kompilatorer kommer generera det som är mest optimalt.

Kod som behöver prestanda och strängar, där brukar jag ha andra lösningar för att få upp hastigheten

Tror inte jag heller men kan du hitta en enda java eller C# utvecklare som ens skulle fundera på att skriva en sådan här lösning?
Det finns inte, att ens diskutera lösningar likt denna är lönlöst

Det råd jag själv fått när jag arbetat i team med C# är att det inte är någon ide. Självklart finns det undantag, alltså utvecklare som vet om annat.

Och det är inte du den första att säga till mig

Tog upp det tidigare i denna tråden, att kod under utveckling är smidigare att jobba med om allt är publikt. Lättare att testa saker.
Och tittar man på objektet så är de metoder som "borde" vara protected eller private statiska med slutklämmen *.s.

Jag menar inte att detta är rätt utan förklarar bara ett annorlunda tänk. Tycker det är viktigt att utvecklare tänker själva och hela tiden funderar över på om det finns bättre sätt att lösa något på

Har du möjlighet att beskriva hur den är lättare.
Jag vet ungefär på vad som är svårt, bl.a. hur du skall radera filer från filen. Hur går de till i din lösning

Förlåt "dumma frågor"

Jag säger först vad som var viktigt för mig.
Ville ha något enkelt index att läsa in över vilka filer som finns där. Därav en representation över filen där varje "entry" har samma storlek. Då blir det så mycket enklare att räkna ut blocket.

Det kommer aldrig bli några mängder med filer ändå.

Denna lista med "entry" är då vad som finns i minnet.

Är det det du menar att varje entry tar för mycket plats?

Jag vet inte eftersom detta är en typ av lösning som inte görs.

Observera att jag inte gjorde lösning för att det är något som inte går i andra språk eller att det skulle vara svårare. Jag gjorde detta för att det inte existerade någon annan lösning. Enda jag hittade var microsofts structured storage men den går inte att använda i linux.

Fråga: Är det viktigt med få rader kod och varför är det viktigt i så fall?

Ursäkta att jag "spammar" tråden och här kommer OT

Men önskar tips på annan ny uppgift. Skulle behöva kod för att hantera formler likt Excel som förutom kan räkna också kan hantera variabler och gärna utföra hopp.
Det absolut viktigaste är att en formel måste vara blixtsnabb att parsa och göras om till funktionalitet. Samtidigt som "uppstart" av att processa formeln bör vara snabb.

Miljön formler körs i är beräkningar och det körs på många processer, små parallelliserade jobb.

Vad jag vet så är snabbast teknik för att parsa "shunting yard", men det kanske finns något bättre. Den är lite bökigare om man behöver möjlighet att hoppa till kod.

Formelhanteringen behöver logik för att "plugga in" metoder, det räcker inte med att hårdkoda så listor med funktionalitet kopplat till namn är viktigt.

LUA är exempelvis alldeles för tungt att dra igång för att göra en jämförelse. Man kan ha en pool med "beräkningsmotorer" också men det har sina problem.

Här förstår jag inte hur du resonerar. Den lösningen jag valde var just för att den är så lätt. Bara att läsa in ett block på vips så är det klart. Ville inte krångla till. "Specialare" eller att optimera får man göra senare, det viktiga är att det fungerar just nu.
Hashmap är visserligen snabbt om det blir en hel del filer, men det går rätt blixsnabbt att hitta ändå och en hashmap drar lite extra minne samt är inte lika cache vänlig som nuvarande lösning är. Menar inte att det är jättecache vänligt nu, det går att förbättra men tror att detta är något processorn fixar.

Den lilla optimering jag själv funderade över är att "headern" eventuellt också skulle kunna ha max längd på varje fil och använda det för att räkna ut storleken på blocket med "entries" men tyckte det var onödigt. Får bli en version två någon gång i framtiden

Ok nu är jag med hur du tänker på att förenkla, att antalet entry inte synkar med filen utan att det först görs när det är dags att spara.
Finns det inte en risk att om programmet smäller så skiter sig filen. Det är viktigt att filerna inte "försvinner". Det var annars något jag la lite tid på att lägga in logik för för så att entry och filer alltid synkar. Det och temporära filen som genereras för att mellanlagra när/om entry behöver växa. Viktigt är att filen är "hel".

Radering är manuell men den är inte lika viktig för aktuell lösning (tror inte radering kommer användas men kan vara bra och ha).

Logiken är sådan att det är jobb som körs på noder med 48 kärnor (tror jag vi kör nu, över det är svårt att skala) och ett arbete kan ta flera dagar. Kraschar det vilket händer så vill man inte tappa det som är gjort. Data genereras i filer och det blir en del men inte supermånga (aldrig över 100). Däremot så är det filer från flera noder som skall samlas ihop.

Absolut inte, att bli bra programmerare är inte alls svårt. Det är just det som är så konstigt idag.
Framförallt två orsaker till att programmerare stannar upp och de är ointresse och blockeringar. Många som läst programmering endast för att få ett bra jobb. De bryr sig inte vad som görs bara det trillar in en lön. Blockeringar är sådana som läst "så här gör man" och slutar att tänka själva. Skolan och universitet anser jag förstört mycket.
Vet att mina kombattanter här anser att jag också är blockerad. Men det är nog de sista någon som arbetat med mig skulle beskriva mig som. Skillnad på hur man uppfattas i text och verklighet och tycker det är otroligt viktigt att programmerare får testa och göra saker som inte är "standard".

Programmering är lätt med rätt träning.

Ja eller jag förstår självklart att det du gjorde var en "quick and dirty" grej för att testa. Men så man inte tänker det är ok för produktion.
Koden jag skrev är mer som en black box men att om det skulle behövas ändras i den så skall den vara lätt att gå in i. Det viktiga då är att den är enkel och debugga och har bra dokumentation samt att jag gjort färdigt, att den inte är halvfärdig.

Nu tror jag vi tar i så vi skiter på oss
Att hitta saker i en vector (array) är inte svårt. Gör jag olika listor så i 9 fall av 10 väljs nästan alltid vector och det har med prestanda att göra. Det skall mycket till innan andra typer av listor slår vector. Ligger man under 100 items så är det i princip inget som slår vector. Dessutom är den normalt snålare i minne (vet att min repository lösning gösslar lite där).

Det är vad jag också trodde (funderade på) att det var din orsak till att välja lösningen. Programmerare idag tänker ofta så och därför är jag (och troligen du med) mycket van att möta det argumentet.
Dagens utvecklare är mycket mer av "pusslare", man letar efter saker som gör det som skall göras istället för att skriva logiken själv. I många fall är det självklart att föredra men det är inte samma sak som att det alltid är bra.

Och framförallt för juniora utvecklare är det mycket viktigt att de själva skriver kod för att träna.

Väljer en utvecklare en annan typ av lista än vector endast för att slippa skriva egen sökhantering och jag är med i teamet så hade jag nog sagt till att välja vectorn och skriva om. Det är inte ett skäl att välja någon annan typ av lista.

Självklart får "repository" klassen funktioner som kapslar in dessa sök i vecktorn. Inget man gör "utanför" klassen.

Det här ser jag faktiskt som allvarligare designfel. Det kräver att utvecklare som använder repository har detaljerad kunskap om hur den fungerar internt. Sådan kunskap skall man enligt mig anstränga sig för att arbeta bort. Krävs sådan kunskap kommer utvecklare bli osäkra på allt för det är svårt och veta vad man måste kunna och vad man inte behöver kunna, därför kommer koden bli mycket mer seg och andra utvecklare lär sig inte skriva kod som "sköter sig själv".

Det behöver den inte göra heller Vad jag vet är diskar fortfarande singelthreaded och även om SSDer är mycket snabbare än vanliga hårddiskar så att ha en sådan flaskhals i trådad kod hade aldrig fungerat.
Vad som sker är att data ligger i minnet och bearbetas/beräknas. När det är klart och går vidare till nästa steg så synkroniseras data och skrivs/läses.

Fråga: Den lösningen du gjorde som jag inte förstod. Hur gör du för att flytta "block" i filen om entry måste växa?
Jag valde att dumpa filens innehåll utom entry till en annan fil. Skriva nytt entry som då går in en bit över filernas innehåll. Sedan läses "dumpen" in igen från den temporära filen men då efter det nya entry blocket som växt i storlek.

Har du en smartare lösning på det?

Addera fil

std::pair<bool, std::string> repository::add(const std::string_view& stringName, const void* pdata_, uint64_t uSize)

Att deklarationen är skriven så beror på överlagring. Du skriver en generell metod som "tar allt". Sedan kan du överlagra med varianter som kallar metoden som tar allt. På det viset får du ett flexiblare API.
Din variant måste ha en vector. Går kan inte skicka in en sträng exempelvis. Och du kan lätt kasta om du har egna objekt.
Du har vant dig för mycket vid rust

I övrigt så dina metoder håller data i minnet. Det fungerar inte för den här lösningen

Filer är stora och i vårt fall kan vi lätt komma upp i över 100 GB. Det är MYCKET data som processas.

Då tycker jag du skall testa och göra en lösning och se vad flaskhalsen blir om du drar igång en massa trådar.

alldeles för osäkert för aktuell lösning

Så kan det vara men att lagra filer internt i minnet tror jag nog är en självklarhet att man inte gör.

Till och med att skriva en parser som läser av någon fil, där kan det vägas fram och tillbaka om den skall läsas in helt eller i sektioner.

Nästan alla typer av enklare storage lösningar har möjlighet att använda minnet för det är så lätt att lägga till. Jag gjorde det för min lösning också men det är inte default.
Orsaken till att man lägger till en sådan lösning är att få en extra feature som är enkel och på så sätt kan de som har mycket arbetsminne dra nytta av det.

Vad du gjort är en slags serializeringslösning, och det är inte svårt. Serializera data är troligen den enklaste tekniken för att spara information. Det är inte vad min lösning skulle göra.

Det kanske finns, jag kan inte vad alla olika linux distros vi använder har för funktionalitet. Windows känner jag till bra men det är fortfarande så att du kan ställa in det här och det är inte obegränsat med minne.
Kör du i molnet behöver man också vara noga med vad man väljer för hårdvara. Det kan snabbt dra iväg prismässigt om man skall ha något "special" och det kan kosta massor.

Vi har en komprimeringslösning men det fungerar inte för det här, måste ha snabbhet och inte göra det onödigt komplext. Det är inte kostnadsfritt att lägga till bibliotek. Ofta mycket mer jobb än vad man tror.

Jag köper visserligen inte den förklaringen men däremot är det inte helt ovanligt att se utvecklare som har taktiken och har svårt att ändra sig.
Vanligt bland python. Ofta argumentationen "det där kan jag slänga ihop på några timmar". Och de kan ofta slänga ihop något snabbt som kanske täcker en lösning som fungerar på 90% eller mer. Men de glömmer av edge cases.
Det som ofta seniora utvecklare används till, de bör förstå alla de udda fall och det som försvårar utveckling ganska rejält.
De utvecklare som inte förstår edgcases brukar snabbt bli sittande i en sörja om det ger sig på sig större saker

Den absolut "bästa" lösningen om det får lov att bli komplext för mitt exempel är enligt det jag lyckades fundera ut att när filen behöver växa så kan man ta filen närmast entry eller om den är liten och man behöver växa över den så får man räkna ut hur många filer som behöver flyttas och läggas sist i filen. Att man roterar filerna. Då slipper man göra en temporär fil men måste räkna om positionerna för för de filer som ligger i filen.

Det blir alldeles för komplicerat för den här lösningen för då kommer andra utvecklare ha svårt att förstå koden.

Det tycker inte jag för att jag skrev nog ganska tydligt att det handlade om en lösning för att spara filer. Då kan man inte "anta" att det fungerar att hantera det i minnet. Default är att det handlar om filer. Tvärtom så borde utvecklare efterfråga extra information för att se om det finns möjlighet att lagra i minnet.

Hade jag givit en utvecklare i uppgift att göra en fil-lösning men den gör något annat, exempelvis minneslösning. Då har utvecklaren inte gjort vad den blev tillsagd att göra.

Lösningen skall inte hårdkodas efter en specifik hårdvara utan skall vara en lösning som inte behöver röras, kanske fungera 20 år framåt.
Det är olika vilken hårdvara óch operativ som körs. Du känner säkert till att i molnlösningar väljs ofta vad som passar bäst för vad man skall göra. Det kan vara allt för olika nästan gratis servrar med svag hårdvara till mycket snabba noder med väldigt många kärnor. Och det kostar

Tack, innan man kritiserar så fråga

Kravet på lösningen är att det skall vara smidigt att hantera en hög med filer. Inte tusentals med mer än 10 (inte varit med att det blir över 100 filer)
Filerna kan bli mycket stora, lätt över 10 GB, vid extremfall strax över 100 GB. Teoretiskt kan de bli över TB men då tror inte jag det är aktuellt med att flytta filer.
Operativsystem varierar. Att "hyra" snabba servrar med snabba diskar är dyrt, därför används de bara så länge det är tidskritiskt och sedan flyttas data till billigare lösningar.

Snabbhet: Bör vara minst dubbelt så snabbt som att lagra information in en sqlite databas. Går det att få 10x så är det bra med.
Prestanda är dock en bonus, inte det viktigaste. Poängen är att det skall vara smidigt för att hålla med med stora filer är tidsödande, spelar ingen roll om de zippas. Blir jobbigt

Filer används bara som mellanlagring, det går inte att lägga in så mycket data i minnet (från början var lösningen sådan men det slog i taket ganska snabbt)

Med det sagt så gör det inte "ont" om lösningen fungerar smidigt med det mesta. Att man slipper fundera över vad som hanteras.