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

Ok men att ens diskutera den processorn är meningslöst eftersom Apple inte tillåter deras hårdvara i andra märken. De är ett slutet system och apple fanboys är helt omöjliga. Allt apple gör är "bäst"

Mitt eller ditt
Tror knappt det finns en känsligare grupp än de som gillar apple. Monopol förstör för oss alla men de blundar för det

Ja men det finns exempelvis mjukvara som bara räknar antalet kärnor och försöker skala efter det och när koden skrevs så var kärnor likvärdiga. Plötsligt kan den koden få problem.

Tack! bra om de försöker jobba bort det

Visual Studio har den funktionen, mycket användbar

Går att backa tillbaka, inte alltid och man får lära sig lite vad som går och inte går.

Apple badar i pengar, vad de säljer är mycket dyrt. Det är många föräldrar som svurit över att deras barn prompt måste ha en apple mobil som är mer än dubbelt så dyr.
Att den är "snabb" spelar ingen roll då det är sällsynt att det går att använda en apple i situationer där det krävs prestanda. Mest utvecklare som gillar datorn och vill trimma sin miljö och tycker det är kul att kasta bort pengar

Eftersom företaget agerar som de gör och gjort tvivlar jag på att någon ens funderar över att satsa på plattformen om de önskar +10 års livslängd eller mer. Går inte lita på monopol.

De andra är inte långt efter men apple är värst.

Förhoppningsvis kan det hända saker här. Personligen anser jag man bör vara orolig för linux för det operativet är mycket viktigt att de inte slukas. Det hade varit mycket bättre om Rust gänget som vill in i linux hade forkat och gjort helt egna varianter. Jag tror risken är stor att om rust gräver djupare in i linux, att de bästa utvecklarna där nu tröttnar. De har inga problem och hitta nya intressantare uppgifter.

Alla jättar inom IT ägs av samma grupper så de håller samman. Ägare skyddar sina ägodelar och de krossade bl.a. Nokia och dyker det upp hot så antingen köper de upp eller infiltrerar företagen.

C++ är inget språk de kontrollerar (än) och viktigt att det framförallt finns flera kompilatorer.

Det är verkligen inte som att önska bort linux (eller windows om man kör där)

I C++ som är ett av de få riktiga objektorienterade språken kan du välja hur du vill skicka data. Default är alltid by value, alltså en kopia. Det är så det borde fungera i andra objektorienterade språk. Du skickar by value för alla primitiva typer,
Det går att skicka referens/pekare självklart men då måste utvecklaren beskriva det.
Skall du skicka by value för klasser i java eller C# så är det genast jobbigare kod.

"coupling", felet med getters och setters är coupling och är en av de värre "code smells" utvecklare kan trassla in sig i.

Skrivs kod som "kopplar" samman funktionalitet och att utvecklaren inte vet hur man hanterar state kommer utvecklaren inte speciellt långt om utvecklaren skall designa arkitekturen själv. Risken är att utvecklaren knappt når 10.000 rader kod innan det är ett trassel som måste slängas.

Att det ändå går göra saker i exempelvis C# är att det ofta är web serverar. Där designas koden efter varje request så det blir nästan som små isolerade delar i koden.

Problemet med DTO är inte så mycket renhet utan att det producerar mängder med kod. Det är inte en lösning som abstraherar funktionalitet. Alltså det är inte en smart lösning. Ta exempelvis en webserver som hanterar en databas på över 100 tabeller. Gör du den med DTO'er räcker det inte med en utvecklare för att bara underhålla systemet. Behövs mycket mer resurser och allt tar väldigt mycket längre tid att ändra i.

Med smartare logik kan en enda utvecklare ganska enkelt hantera system som har över 500 tabeller och det går att slänga bort gigantiska mängder kod.

Ofta bryr sig inte java eller C# utvecklare om sådant, arkitektur är inte prioriterat

"Så här funkar det i C++ och därför borde det göra det i alla språk för C++ har alltid rätt" ?
Nej, det "borde" inte fungera på ett visst sätt i något språk bara för att C++ beter sig på det sättet.
Om all data skickades som kopia skulle det äta onödigt minne. Särskillt med tanke på att immutable objekt föredras så är det fullständigt onödigt att kopiera dem.

Jag ser getters (och ibland setters) främst i DTO för åtkomst till dess innehåll. Jag ser inte hur det bidrar till coupling. En bit kod som använder en DTO, antingen den instantierar den själv eller får den i retur från ett anrop, behöver väl allt som oftast också läsa dess data? Eftersom vi har inkapsling som princip så är väl getters ett utmärkt sätt att lösa det?

Källa på det? Det låter som antingen påhittat eller fördom.
"Ofta bryr sig juniora/oerfarna/stressade/dåliga utvecklare inte om sådant" är nog närmare den verklighet jag arbetar i. Det är inte språket som avgör vad en utvecklare bryr sig om.
Farligt nära där att man kan tolka det som ett det skulle finnas en korrelation mellan "inte C++" och "sämre".

Det säger jag inte utan jag sa hur objekt bör fungera. Skall du skicka by value (vilket ofta är önskvärt) så har du problem i språk som C# eller java. Är du med?
När man skickar pekare så tappar du en del kontroll, du måste följa vad som händer eller designa kod så det blir smidigare.

Då minskar du på lösningsmöjligheter.

Ok, du har aldrig skrivit parallelliserad kod? 6 kärnor eller mer är väl mer eller mindre standard. Svårt att skriva den typen av kod om du skickar pekare och alla trådar jobbar med samma data.

Det här är enligt mig en orsak till att Microsoft troligen kommer minska fokus på C#. C# för dem är en pengamaskin men kan de inte tjäna pengar på språket så varför skulle de underhålla det.
Lösningarna som C# används för nu kan ganska enkelt tas över med AI så de tappar vinsterna

Det här är ett gigantiskt område, tar tid att lära sig men väl investerad tid i att göra. Har man inte sett två olika lösningar som gör samma sak men där den ena är gjord med DTO objekt och den andra tillåtit smartare lösningar tar det ett tag att förstå. Har man däremot lärt sig andra tekniker kommer man inte ens fundera över att att använda DTO för annat än där det handlar om specifik funktionalitet.
DTO'er gör:
- Svårare att byta ut utvecklare, utvecklare behöver lära sig domänen
- Producerar mycket kod
- Kod är mer eller mindre hårdkodad
- Producerar ofta duplicerad kod, nästan samma sak görs på flera ställen
- Kräver mycket underhåll, behövs inte mycket som skall ändras för att koden behöver förändras
- Coupling
- Kräver ofta ganska komplexa byggpipelines, är koden fylld med "copuling" behöver man mer kontroll så inget gått sönder

Finns mer men det är en bedrövligt dålig lösning. Enda orsaken till att välja den är om man vill slänga ihop något snabbt och har svårt att få tag i utvecklare duktiga på arkitektur. Tyvärr vet inte många om det och sitter i en salig sörja med massa utvecklare

Kalla det slutleldningsförmåga eller tänka själv istället för att vara rädd för att uppfattas som konspiratorisk.
Fler operativsystem är bättre än färre och flera bra lösningar har förstörts. Nokia hade sin version på gång, blackberry är en annan. De lever idag men i mindre skala.
Browsrar är annat exempel. Idag använder i princip alla utom firefox en och samma grund (WebKit) som grund. Det är inte hälsosamt för innovation när nya lösningar blockeras.

Skulle en grupp få för sig att göra en egen renderings-motor för webben så är det ett omöjligt projekt även om den görs bättre och det beror på att andra stora aktörer täppt till.
Jag tror många projekt aldrig startas just för att marknaden monopoliserats (några få kontrollerar allt).

Hur vet jag det?
På 1990 talet när jag började arbeta som programmerare kunde du nästan göra vad som helst, allt gick att sälja för allt var så nytt. Bara här i Sverige fanns massor av produktbolag, levde på egenutvecklade produkter. Gjordes något bra så gick det att sälja.

Någon gång mellan 2005-2010 började marknaden förändra sig och lagar och annat har förändrats som gjort det mycket svårare för mindre aktörer. Mjukvara som utvecklas idag håller ofta sämre kvalitet än den som gjordes förr. Programmering har gått tillbaka senaste 10-15 åren men det maskeras med att miljöer och annat blivit bättre.

AI tror jag kommer ändra på det här för AI är enligt mig något större bolag har svårt att kontrollera. Med AI kommer grupper som är små men duktiga ändå kunna producera väldigt mycket värden.

Rust i Linux
Ja jag vet att det endast är i några externa projekt nu men ser väldigt många som vill in djupare och det förstår jag inte.
Bland det svåraste som finns (vet ingen som lyckats) är att få programmerare med olika mål/drifter att jobba bra ihop. Programmering är så starkt känslomässigt för de som blir "bitna" och alla gillar att skapa. Därför är det bättre att dela upp där de kan få fria tyglar i rätt miljö. Det är då utvecklare kommer prestera och skapa bra saker.

Tror det vore kanon om ett gäng i Rust gjorde en egen variant (eget OS) för det hade varit bra för alla

Svarar inte här utan varit upptagen med att fixa till koden för att hantera ett repository.
Inte så märkvärdigt som det låter, det är en fil som kan lagra flera andra filer i sig. Precis så "klart" att det fungerat när jag testar men behöver slipa till den hårdtesta innan det är produktionsfärdigt.

Här är en länk till koden (både header fil och cpp fil i samma)
https://hastebin.com/share/orefaquyis.cpp

Gjorde den här bilden också men det verkar som den förminskas... Lägger in och får göra något annat
Det är i alla fall den röda mitten rutan som är den viktiga för att använda objektet "repository". Resten är inte intressant utåt

Det finns en del lösningar i den här koden som vad jag vet är mycket ovanligt att man ser idag. Bl.a. används tekniken "hungarian notation". På windows från början på 1990 till strax innan 2010 var den stilen extremt vanlig för C/C++ utvecklare.
Nästan alla jag känner från tiden som skrev C++ för windows använde det vid utveckling. De flesta där har "tvingats" bort då det sällan accepteras idag vilket är synd. Stilen är fantastiskt effektiv.

Tittar man på koden så är den skriven för att slippa "hoppa runt". En utvecklare måste alltid förstå koden utan att behöva hoppa runt i filer. Det är därför det finns prefix och postfix. Exempelvis har alla statiska metoder *_s, Globala har *_g och så vidare.

Tänkte få ihop någon liten exe som kan användas för att göra backuper men det får bli ett projekt till nästa helg.
Hittade inget för det här så det är orsaken och eftersom vi diskuterar kod blir det här lite mer realistisk kod istället för småsnuttar även om det är lite detta också.

När jag skriver kod försöker jag hålla koden så ren som möjligt från kommenterar och felhanteringskod. Kommentarer är det gott om men de är "runt" koden. Felhaneringskod kan bli långa rader. "assert" flyttas ut till höger i marginalen.

programmering, det man gör med språk och det är ganska centralt

När vi käftar fram och tillbaka här vilket språk som lämpar sig bäst för att göra saker så är vi ändå ganska långt från vad som spelar roll. Kan programmeraren skriva bra kod och hålla samman stora projekt. Om det tar från några veckor till kanske ett år eller mer att lära sig ett språk. Nästa språk går mycket snabbare att lära sig. Mest att träna in en ny syntax.

Men det är först dåresan börjar för att lära sig programmera.

Tittar jag på annan utvecklare så spelar det mindre roll hur tekniskt den är, alltså hur mycket teknik den kan. Det viktiga är att den klarar att förstå problematiken med att hantera mycket kod.

Om en utvecklare då tycker det är svårt att hantera minnet. Då är det ett tecken på att om en sådan sak som ändå utvecklaren bör klara om utvecklaren skall vara med i större projekt utan ramverk, alltså projekt där utvecklare måste lösa problem själva.
Kan inte utvecklaren hantera minne, hur skall då utvecklaren hantera allt annat så är så mycket svårare?

Att minnesbuggar är allvarliga på det viset att programmet kraschar men de är också lätta eftersom det inte går att missa. Andra buggar som är mindre allvarliga, de är mycket svårare att lära sig hantera eftersom de inte upptäcks lika enkelt.

Ovanstående går självklart att utveckla men det förklarar varför C och C++ fortsatt kommer dominera. Det är där man hittar de utvecklare som kan hantera mycket kod.

De utvecklare som jag sett skriver kod i C# eller Rust på senare tid. Det är för mycket fel i koden, behöver inte vara buggar men fel som gör att det blir svårt att göra smarta lösningar. En van utvecklare kan snabbt se när andra utvecklare som är juniora eller kanske medel. Att de kommer trassla in sig.

Problemen med "minnessäkra" program som har mycket gratis i språket. Java och C#, där får man med mycket logik som är standardiserad. Alla utvecklare där har tillgång till samma färdigskriven kod. Rust prisar ofta sitt Cargo mm. Det är för lätt för utvecklare att ta sig en bra bit utan att lära sig hantera kod.
När det är så lätt, då blir annat som är bra att kunna för att hantera svårare saker så mycket mer svårare eftersom utvecklaren knappt får någon träning.

AI och hur det kommer separera utvecklare
Den koden jag postade, har spenderat c.a. 16 timmar (två fulla arbetsdagar på den). Utan AI tror jag det skulle ta mig kanske en vecka men då utan lika välskrivna kommentarer. AI är otroligt på att kommentera upp koden.

AI är både lätt och svårt. AI hjälper till bra för allt som är lätt, effektfullt hur bra AI ibland gissar. Speciellt om man följer standarder och koden följer fasta mönster. Om utvecklare skriver mer "rätt", desto mer nytta av AI.

Svårt blir det för att när AI inte kan hjälpa eller gör fel. De utvecklare som inte tränat sig i att skriva kod kommer få större problem. Att vänja sig vid enkelheten att låta AI göra jobbet och sedan växla om till att själv börja detaljgranska. Tror inte många kommer göra det.

IT jättar som kommer arbeta om sina affärsmodeller
IT monopolet tror jag kommer förändra sig ganska ordentligt och de har säkerligen jobbat på det ett bra tag. Det kommer bli mycket svårare att blockera konkurrenter med kod.
Små utvecklarteam tror jag kommer kunna producera enorma värden och slå sig in och jag tror inte man hittar dessa team bland de språk som ger för mycket hjälp för utvecklare. Det beror på att dessa språk inte låter utvecklare träna på saker som är viktiga att bli duktig på.

Det säger jag inte utan det jag säger är att C/C++ är bästa verktyget för de som behärskar språket. "Minnessäkra" språk erbjuder inga fördelar men en hel del nackdelar för utvecklare som klarar C++

Kan man inte C/C++ eller har problem med språket så tycker man självklart inte samma men det har inte med att språket är dåligt att göra. Språket har för mycket frihet eller för få säkerhetsbälten om man kan uttrycka sig så.

Vill du koda "minnessäkert" så kan du göra det i C++. Lägg allt i smartpointers eller andra containerklasser så är du hemma

Om minne inte är ett problem för en del utvecklare då? Skall du tvinga dem till att något är ett problem när det inte är det

Ja C är inte C++ men C används ofta för att de måste, det finns inget annat i de system du räknar upp

Säkert men det finns också programmerare som inte är så intresserade och tycker det är jobbigt. Istället för lära sig anklagar de andra som försöker lära sig för att skryta.
Lägger man tid och försöker lära sig så blir man bättre. Självklart beror det på mycket hur men utvecklare som aldrig tränar på saker som är bra att träna på, de stannar ofta upp.

Personligen tycker jag det är en av de saker som är så kul med programmering, lär man sig tekniker får man direkt utslag för det. Det går alltid att lära mer och förbättra sig