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

Nu blev det ytterligare en uppräkning om att HN är bra utan väldigt lite varför.

Ok, det är kan vara en fördel, men en av poängerna med auto är väl just att man kan slippa bry sig om exakt vad det är för typ på variabeln? Någonting kom från ett funktionsanrop och skall skickas vidare till ett annat funktionsanrop och då är det kanske inte så viktigt vad detta objekt har för typ. Är det vitalt att det är en uint64_t då kan man klämma dit det i deklarationen.

Nu förstår jag inte varför domänen skulle bli lättare för att man dekorerar sina variabler med typprefix. Det kommer väl rimligen vara samma konstiga namn i den flexibla delen. Om det är en komplex domän är väl den i sig magnituder svårare än ha hålla koll på om en variabel är en pekare eller inte? Om inte programmeraren klarar det utan prefix är det nog kört för projektet ändå.

Varför skulle saker och ting få mer varierande namn om man inte kör HN? HN-användaren och icke-HN-användaren drabbas väl av exakt som problem när man skall sätta ett relevant namn på flex-delen av variabeln? Här vill man förmedla saker som användning, innehåll eller roll och namnsättning är svårt, men det är väl lika svårt oavsett om man kör HN eller inte? Varför drabbas inte HN-användaren av olikhet och slarv för flexdelarna av namnen?

Nu vet jag inte hur prefixet skulle se ut för lista av something, men jag måste ju erkänna att en variabel som p_list_something_first kommer vara mer lik p_list_something_last än variabeln first är lik last, så i någon mening får du säkert mer likformiga namn om du använder HN. Men å andra sidan, så drunknar, de i mina ögon mest relevanta delarna av namnen, first och last helt i prefixet. Blir det verkligen lättare att läsa och förstå? Vad har jag missat?

Härligt, vi är tillbaka på ruta ett

Japp, @klk är verkligen immun mot information...

Hmmm...
I korthet kan man säga att man i imperativ programmering talar om vad som ska göras medan man i deklarativ programmering talar om vad man vill komma fram till.
Så, i imperativ programmering säger man med hjälp av imperativer "gör så här så får vi se vad det blir för resultat".
I deklarativ programmering säger man "här är egenskaperna hos det resultat jag letar efter, hitta de data som tillsammans motsvarar de egenskaperna om det finns sådana data".

Något förenklat så:
Imperativ kod beskriver hur något skall göras.
Deklarativ kod beskriver vad som skall göras.

Om vi tar ett nästintill trivialt exempel: En funktion fac(n) som skall beräkna fakulteten av ett naturligt tal n.
(Skrivet i pseudokod, men det bör inte vara svårt att översätta till valfritt programmeringsspråk)

// Deklarativ kod
fac(0) = 1
fac(n) = n * fac (n-1)

// imperativ kod
fac (n) = {
    res = 1
    for i = 1 to n
        res = res * i
    endfor
    return res
}

Eller om vi tar ett lite mer avancerat exempel: Hitta poster i en databas. Återigen pseudokod, och långtifrån optimal kod

// Deklarativ kod
SELECT name FROM students WHERE age >= 18

// imperativ kod
result = []
table = find_table(students)
len = get_num_entries(table)
for i = 1 to len
  entry = table[i]
  if entry.age >= 18
    add_to_array(entry, result)
  endif
endfor
return result

Som synes så brukar imperativ kod bli mer detaljorienterad och man måste oftast hålla reda på en massa mer tillståndsinformation än i deklarativ kod.

Fast nu är det framförallt du som säger felaktigheter i denna tråden. Alla hjälps ju åt att rätt din konstanta felanvändning av termer.

Det enklaste är ju om du bara läser Wikipedia så kommer du ju ha samma definition som alla andra i världen. Något säger mig att det inte kommer fastna denna(typ 8:e gången) gången i heller.

Deklarativ/imperativ är bara paradigm. Paradigm kan enkelt förklaras som en samling karaktärsdrag hos språken.

Imperativt kan enklast beskrivas som att man som utvecklare stegvis säger hur saker ska utföras.
Deklarativt kan enklast beskrivas som att utvecklaren beskriver vad som ska uppnås.

Exempelvis välja jämna tal ur en lista. (Pseudokod så det inte triggar igång dina Python-trauman)
Imperativt:

all_nums = [1,2,3,4,5,6]
even = []

for num in all_nums:
  if (num % 2) == 0 :
    even.add(num)

Förklaring:
Fokuset ligger på stegvisa instruktioner som följer
1. välj ett tal från listan
2. beräkna modulo
3. om resultat är 0
4. lägg till i resultat lista

Deklarativt:

all_nums = [1,2,3,4,5,6]
even = all_nums.map(|x| (x % 2) == 0)

Förklaring:
Genom valet av map()-operationen ihop med villkoret så fokuserar vi framförallt på vad som ska uppnås utan att fokusera på stegen dit.

Notera att detta enbart är olika sätt att programmera, inget är nödvändigtvis bättre eller sämre utan annorlunda. Under deklarativa språk så hittar du alla funktionella språk: haskell, prolog, ocaml, erlang. Ett karaktärsdrag som brukar överraska folk som börjar med funktionell programmering är att dom oftast(säger detta som en reservation för att jag inte har koll på alla funktionella språk) är avsaknad av loopar(for, while, osv) och man löser detta istället med tail-recursion.

Om vi tar ditt favoritspråk Python, som du brukar kalla deklarativt, så brukar det skrivas med många if-statements och for-loopar och väldigt lite iterator-funktioner, vilket tyder på att Python framförallt är ett imperativt språk. Sedan kan du skriva till saker som iterator-funktioner och få till en programmeringsstil som efterliknar funktionell-språk men detta kan du i alla imperativa språk även C++.

Nöjd? Kan du absorbera detta nu så vi slipper ha denna diskussionen en 9:e och 10:e gång?

Att skriva ingen kod alls är viss mening optimalt för både deklarativ och imperativ kod - nämligen i de fall när man konstaterar att vissa operationer inte behöver göras och man därför kan optimera bort hela kodavsnitt.

Men är det något som behöver göras så behövs kod, man kan inte göra det med ingen kod alls. Så att säga att målet med deklarativ kod är att inte skriva någon kod alls, det stämmer inte.

Även om deklarativ kod oftast blir kortare och mer koncis än imperativ kod, så har den inte andra mål än imperativ kod.
Att skriva liten mängd kod kan vara bra, men betydligt viktigare är att den kod som skrivs är begriplig. (Koden bör naturligtvis också vara korrekt, effektiv, testbar, m.m. men att den är begriplig är en bra början.) I det avseendet så är det ingen som helst skillnad mellan imperativ och deklarativ kod.

Även när man skriver imperativ kod så är det vanligtvis mängder av detaljer där man inte behöver fundera på exakt hur det görs - man bara litar på att kompilator och hårdvara gör något bra.
Exempelvis en enkel kodrad som a = b * c kan implementeras på många olika sätt. Variablerna kanske ligger i hårdvaruregister, eller på stacken, eller på någon annan plats i minnet. Multiplikationen kanske görs med en enda CPU-instruktion, eller så kanske en biblioteksrutin behöver anropas. Och så vidare.
Så fort man kommer steget ovanför ren hårdvarudesign så innehåller all programmering deklarativa element där man inte tänker på hur något görs.

Det är inte varandras motsatser det är inte jedi vs sith. Många moderna språk implementera funktionella aspekter eftersom många utvecklare uppskattar dessa som iterator-funktioner som map, filter, fold. Detta gör språket mer attraktivt för en bredare massa. Rust och Go har det och jag skulle misstänka att C++ har det in någon utsträckning beroende på hur moderna dom vill uppfattas.

Sedan nu kopierar du och repeterar från @Erik_T men det du skrev ursprungligen var:

Vilket är en helt annan sak än vad som ska lösas eller hur något ska lösas. Många utvecklare skulle hävda att funktionell(dvs deklarativa) lösningar är bättre än imperativa (har för mig att @Yoshman pratat om optimeringar relaterat till iterator-funktioner i Rust).

Ingen lär ha skrivit den koden, gissat att det är en C de-compiler. Som i min mening gör ett fantastiskt jobb om den bara hade assembler att utgå från.

Rätt säker att de använder retdec-decompiler (https://github.com/avast/retdec)

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
    if (argc < 2) {
        printf("Usage: %s <int1> <int2> [int3 ...]\n", argv[0]);
        return 1;
    }

    int sum = 0;

    for (int i = 1; i < argc; i++) {
        int value = atoi(argv[i]);
        sum += value;

        printf("%s", argv[i]);
        if (i < argc - 1) {
            printf(" + ");
        }
    }

    printf(" = %d\n", sum);

    return 0;
}

// Address range: 0x1080 - 0x1141                                     
int main(int argc, char ** argv) {
    if ((int32_t)argc < 2) {
	// 0x1124                                                     
        __printf_chk(2, "Usage: %s <int1> <int2> [int3 ...]\n", argv)\
;
        // 0x1115                                                     
        return 1;
    }
    int32_t v1 = 0; // 0x10b4                                         
    int64_t v2 = 1; // 0x10b4                                         
    int64_t * str = (int64_t *)(8 * v2 + (int64_t)argv); // 0x10b8    
    int32_t str_as_l = strtol((char *)*str, NULL, 10); // 0x10c3      
    __printf_chk(2, "%s", (char *)*str);
    if ((argc + 0xffffffff & 0xffffffff) > v2) {
        // 0x10e2                                                     
        __printf_chk(2, " + ");
    }
    // 0x10f5                                                         
    v1 += str_as_l;
    v2++;
    while (v2 != (argc & 0xffffffff)) {
	// 0x10b8                                                     
        str = (int64_t *)(8 * v2 + (int64_t)argv);
	str_as_l = strtol((char *)*str, NULL, 10);
        __printf_chk(2, "%s", (char *)*str);
        if ((argc + 0xffffffff & 0xffffffff) > v2) {
            // 0x10e2                                                 
            __printf_chk(2, " + ");
        }
        // 0x10f5                                                     
        v1 += str_as_l;
	v2++;
    }
    // 0x10fe                                                         
    __printf_chk(2, " = %d\n", (int64_t)v1);
    // 0x1115                                                         
    return 0;
}

Vi är absolut överens om override.

Vad överlagring faktiskt refererade till i det ursprungliga sammanhanget här i tråden måste jag erkänna att jag inte har den minsta uppfattning om. Jag tappade spåret någonstans vid en telefonbok. Jag var helt inne på vad termerna betyder rent generellt, därmed brasklappen att jag knappast tillförde något vettigt till tråden.

Jag måste erkänna att jag med facit i hand bara skulle ha fortsatt äta popcorn och titta på spektaklet som är denna tråd istället för att bli en del av det själv. Lätt att vara efterklok!

Jag hoppas att du förstod att jag menade att du i min uppfattning är påläst (i mångt och mycket långt över min egen kunskapsnivå). Inte att du behövde läsa på ytterligare. Jag försökte alltså säga att jag respekterade din åsikt även om den inte stämde överens med min.

Att minska mängden kod som behöver skrivas är precis lika viktigt eller oviktigt när man skriver imperativ kod som när man skriver deklarativ kod. Och är sällan ett primärt mål i endera fallet. Så har man det målet, tänker man oftast fel.

Nu håller du nog på och försöker jämföra äpplen med päron motorcyklar.
Imperativ kontra deklarativ programmering har lite eller inget att göra med hur kod är strukturerad. De är snarare två olika sätt att tänka när man skriver kod.

Producent och Konsument är lite olyckligt valda termer för att diskutera kodstruktur, eftersom Producent-Konsument redan har en väletablerad betydelse i programmering, nämligen att beskriva ett visst mönster i multi-process kommunikation.

Anledningen till att man snabbt kan hitta vad man söker efter i en telefonkatalog är inte primärt på grund av hur informationen på en sida är strukturerad, utan det är på grund av att informationen är sorterad så att man kan göra en snabb binärsökning på namn för att hitta rätt telefonnummer, iställer för att behöva läsa igenom hela katalogen från början.

Skulle man istället ha ett telefonnummer och försöka hitta vem som har det, så går det inte snabbt att hitta det i en telefonkatalog trots att informationen finns där, då den inte är sorterad efter nummer.

Så länge telefonkatalogen är sorterad efter namn, så spelar det inte så stor roll om enskilda poster är strukturerade som (namn, telefonnummer, address) eller (telefonnummer, namn) eller (address, namn, telefonnummer).
Det går ändå snabbt att slå upp ett telefonnummer baserat på namn, och att ha alla poster strukturerade likadant skulle bara hjälpa marginellt.

Ja exakt. Du använder ord som redan har väldefinierade betydelser. När du istället borde förklara vad du menar (utan omdefinierade termer). Du får leva som du lär helt enkelt.

Jag menade bara: vi har ju gått på samma skola, om något fick man där lära sig att lära sig. Du lyfte faktiskt en sak jag aldrig reflekterat över innan: vad är ett vettigt namn för "overload" på svenska.

Vi har ju en annan favorit som brukar ställa till problem på svenska, "säkerhet". Är det eng. "safety" (som tråden handlar om) eller "security"? Precis som "strålspårning" nog är mer förvirrande än bra, ray-tracing fattar de iblandade, kanske man ändå bör använda "overload" och "override" även på svenska.

Sen tror jag ändå det relevanta i slutändan bara är att alla är variationer på polymorfism, vilket i sig är superanvändbart.

Så "absolutely no offence taken", det är ju en diskussion och den är klar när man nått konsensus (vilket aldrig lär hända i en tråd på Internet...)

Inser hur träffsäker "telefonkatalog" ändå blir över hur jag, efter många försök att faktiskt förstå, känner kring saker som HN och andra saker kring "strukturering av kod" du nämt.

Sedan ~2000 är "telefonkatalog" en benämning på en samling information, som inte sällan ny-publiceras med jämna mellanrum, en benämning på information som är i praktiken 100 % redundant och som nära nog ingen längre bryr sig i. Men det är ändå en källa som historiskt hade ett värde.

Nu har väl ändå "producent" och "konsument" inom "concurrent programming" varit rätt vedertaget i alla fall sedan 1978 när Tony Hoare presenterade sitt CSP (Communicating Sequential Processes) paper?

?? Sambandet med det jag skrev ??

Vitsen i det jag skrev är att det inte är lagringen som är problemet utan indexeringen av det som finns lagrat.

Sen har jag hittat i geeksforgeeks-sidan jag refererade att man såg en nackdel i att det blir mycket läsning från disk men med de B+-träd vi använde fanns inte det problemet eftersom vi bara lagrade nyckelvärden i träden och att träden hölls i primärminne hela tiden (enstaka index kunde vid hög belastning tillfälligt hamna i virtuellt minne). Responstiderna hölls på millisek-nivå.