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

Eller så handlar det om C/C++, två språk som totalt dominerar sett till vilken typ av maskinkod som körs på datorer. Om det är kanske 90% av all aktiv maskinkod som är kompilerad C/C++ ligger det nog ganska nära sanningen.

Trots dominansen är det få som skriver C/C++ kod. Tar man hela programmeringskollektivet rör det sig säkert om färre än 20% och det beror ofta på att det är en något annorlunda värld jämfört med andra typer av språk.

För att det är en så tråkig utveckling. Äldre arbetskamrater har givit upp, de orkar inte diskutera med personer som precis lärt sig programmera och tror de är världens bästa programmerare.

Det finns inget rätt eller fel inom programmering och det borde alla som pysslat med programmering veta om. Det finns bättre och sämre men vad som är bättre eller sämre beror på massa andra faktorer.

I tråden som handlar om minnessäkerhet, en nybörjare i C eller C++ är farlig för det kommer bli problem. Men det är inte samma sak som att det är problem för alla.

Bad AI skriva ett exempel (orkade inte skriva själv)

-- Method 1: JOIN in FROM clause (Modern ANSI SQL Syntax)
SELECT 
    c.customer_name,
    c.email,
    o.order_id,
    o.order_date,
    o.total_amount
FROM customers c
INNER JOIN orders o ON c.customer_id = o.customer_id
WHERE o.order_date >= '2024-01-01'
ORDER BY o.total_amount DESC;

-- Method 2: JOIN in WHERE clause (Older Syntax)
SELECT 
    c.customer_name,
    c.email,
    o.order_id,
    o.order_date,
    o.total_amount
FROM customers c, orders o
WHERE c.customer_id = o.customer_id
  AND o.order_date >= '2024-01-01'
ORDER BY o.total_amount DESC;

Byggs logik för att automatiskt generera och det skall vara enkelt för de som anpassar applikationen ställde det här till mycket mer problem än vad man kanske först kan tycka. Räkna ut vad som skall inkapslas i parenteser mm blev komplicerat

Jag förstår faktiskt inte varför du kritisera mig isåfall för det tyder på stort databasintresse. Jag tror faktiskt inte det finns mer än en handfull personer i Sverige som jobbat lika mycket med databashanering som jag gjort. Man lär sig och hur man med olika trick kan få till mängder med funktionalitet.

Ser jag någon annan som är duktig på databaser är det intressant och man blir nyfiken

Om du bara visste hur komplex kod man tvingades skriva för att hantera långsamma uppkopplingar eller replikering.

Säljare som åkte utomlands kunde inte koppla upp sig mot central databas. Men de måste ändå kunna mata in uppgifterna. Det skedde då lokalt och sedan när åkte in på kontoren synkroniserades deras data med central databas, det var så man kunde lösa CRM för resesäljare och andra som reste.

De som gör system idag är inte i närheten av samma komplexitet

Det är ett mycket stort område branschen är, finns mängder av olika områden och att ha erfarenhet inom en något innebär inte på långa vägar att man kan allt.

Det tråden handlar om är kritiken mot minnessäkerhet mot C/C++ även om tråden pratar om en hel del annat och det är kanske inte så konstigt att tråden då samlar personer som inte gillar C/C++. Eller kanske inte lyssnar på C/C++ utvecklare som kommit så långt så de vet hur man skall använda språket.

Du kan koka ner min argumentation till ett enda område och det är brukar idag kallas för data orienterad design. Förstår man hur det skall användas och vad det handlar om så går det inte att slå om det är två likvärdiga som tävlar där ena använder tekniken och de andra inte gör det.

Har använt tekniken för flera olika applikationer jag varit med och tagit fram, går i princip inte att misslyckas.
Det är faktiskt inte ens svårt

Om man blir sur över att få mycket bra tips inom programmering, Hur tänker man då?

Finns flera orsaker till varför DOD är så effektivt, inte bara att det blir snabb kod. Den viktigaste enligt mig är troligen att man inte trasslar in sig.

Utvecklar lite med ett exempel som kanske ger bra insikt om DOD (skriva kod kring data och system domänen istället för användardomänen).

Stort problem att skriva WIn32 applikationer med dialoger och annat from common controls är att hålla reda på id.

Varje del i en dialog (knapp, editbox, dropdown mm) har ett id men också en "handle". De här ID numren används för att hantera värden, fånga upp knapptryckningar mm.

Hårdkodas värden mot användardomänen, att exempelvis man mappar edit kontroller direkt mot fält i databasen, det är det vanliga men det blir problem när något ändras. Annan logik som att "tömma" (nollställa) fält får göras separat för varje dialog. Större databaser och det blir massor av ID att hålla reda på (man trasslar in sig).

En data orienterad lösning (DOD) kan istället se ut som att lösningen struntar in användar domänen och istället fokuserar på system domänen, Hur fungerar det i operativsystemet.

Då skulle olika typer av kontroller kunna få olika sekvenser. Låt säga att alla edit kontroller får sekvenser mellan 1000 - 1999, knappar sekvenser mellan 2000 - 2999 och så vidare.
Istället för att ha ID nära slumpvis för varje värde går det istället att använda ID och samtidigt veta en del för inte bara att man nu kan bygga återanvändbara metoder (lätt att skriva metoder som alla dialoger använder för att tömma sig eller annat), numret berättar också vad det är för typ av kontroll.

CRM systemet jag var med och gjorde, där använde vi den här tekniken för det var massor av dialoger, men varje dialog hade inte speciellt mycket kod. Programmerarna behövde heller inte lära sig "användardomänen". Beskrivning hur fält mappades med dialoger klarade personer som var kunniga om det (hur programmet skulle fungera) göra.

En ganska simpel lösning som sparade massor med tid och vi slapp trassel

Eller så är det du som inte förstår

Jag postade tidigare en video och gör det igen, om du tror jag är ensam
Länk till inlägget: #20950484

Förr eller senare tror jag man är så illa tvungen. I och med LLM så blir de som lär sig så extremt effektiva samtidigt som LLMer nära nog kan ta över användardomäns programmering.

Påstår inte att det är bra för antalet programmerare som behövs tror jag kommer minska.

LLM är ett verktyg och verktyg kan användas olika. Pröva att förträna LLM med HN får du se, den snappar upp det direkt.

Man blir mycket snabb med LLM men om utvecklaren inte är van att producera välstrukturerad kod kommer utvecklaren bli snabb på att producera skit.
Om utvecklaren däremot vet hur man producerar strukturerad kod kan utvecklaren bli mycket snabb på att producera bättre kvalitet.

Så det som sker nu är att skillnaden mellan senior och junior utvecklare blir större

Nu är jag kanske bara aktiv i den här tråden va, mycket sparsamt med inlägg i något annat

Det beror på att det är skilland på praktisk erfarenhet och teoretisk erfarenhet. Har man bara teoretisk erfarenhet så har man bara läst om något, man tror att det man läst är rätt. Det kan vara rätt men det behöver inte vara rätt. Personer med praktisk erfarenhet kan mycket snabbt märka om någon "bara" har teoretisk erfarenhet, man vet liksom vad som är svårt för man har slitit själv med det.

Har du praktisk erfarenhet så vet du, då har du prövat och förstått.

Många som läser tolkar också saker känslomässigt, ingen hinner läsa allt. Skrivs ett längre inlägg så kan eventuellt en läsare snappa upp en liten del. Är det då något i denna del som är negativt brukar det vara det man minns.
Därför kan ibland två som håller med varandra ändå misstolka varandra eftersom de inte läser vad de skriver.

Och för att applicera ovanstående på tråden (praktisk jämfört med teoretisk). Det är många C/C++ programmerare som inte förstår kritiken mot språket eftersom de har praktisk erfarenhet och inte upplever det som ett problem. Minneshantering är bland det första man lär sig, går liksom inte att undvika eftersom det smäller annars.

C++ har konstruktorer och destruktorer, normalt raderas allokerade minnesblock i destruktorn. Det gör de flesta och gör man det så är problemet löst med minnesläckor (oftast i alla fall). Tolkar inte som just minnesläckor är problemet för då borde inte rust användas som föredöme eftersom det tydligen är vanligt med minnesläckor där också.

Har jag förstått rätt är det huvudsakliga problemet med att skriva/läsa till områden man inte får läsa/skriva från

Säkert och när den applikation jag refererat till, när vi skrev den hade jag arbetat med utveckling i drygt 1 år.
Det jag lärde mig på var anställningen innan, min chef där var mycket duktig och vi gjorde ett deklarationsprogram. Det lärde jag mig massor av

Hur länge man programmerat är enligt mig ett dåligt mått.

Ett annat exempel som jag tror jag nämnt i början på tråden om EHPT. EHPT gick egentligen i konkurs men Ericsson svalde dem (3000 anställda). Att de skulle gå i konkurs kände jag till c.a. 2 år innan de gjorde det och hur kunde jag göra det?
En vän till mig arbetade där och beskrev om deras problem i arkitekturen, att den aldrig skulle klara av de krav de hade. Men han vågade inte berätta eftersom han "bara" var kodslav. De hade investerat så mycket pengar i en ny produkt, hur berättar man för chefer och ledning att det inte kommer fungera?

Han bollade alltså bara ideer om hur man skulle kunna förklara för chefer som inte förstod det tekniska. Han gjorde ett försök men det bet inte så det gick som det gick.

Det här förloppet tror jag är jättevanligt med tanke på hur många krashade projekt som finns.