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

Återigen visar du att du svänger dig med uttryck som du inte begriper. Om något är logaritmiskt så betyder det att problemen minskar ju större koden blir. Det du antagligen är ute efter är exponentiell ökning (inversen av logaritmisk) men även där beror ökningshastigheten på basen, Är exponenten 2 kommer en ökning av kodbasen med 2 innebära att problemen (om vi utgår från att de finns) potentiellt ökar till 4 gånger flera.
Men det är ett underligt mått i samband med programkod, det används mest när man talar om komplexitet, framför allt när det gäller minneskomplexitet eller programkörtid, oftast i jämförelser mellan olika implementationer.

Det här börjar bli löjligt. För varje gång det visar sig att du har fel eller inte lyckas visa vad du menar så hittar du en annan vinkling för att fortsätta pladdret.

@serafim @klk Flera referenser jag har hittat nämner uteslutande C och ASM för själva kärnan. Denna video av Raymond Chen förklarar det bäst.
https://learn.microsoft.com/en-us/shows/one-dev-minute/one-de...

Även David Delaune lutar åt det hållet även om han inte explicit nämner kärnan i sig. (Vilket för Windows del kan vara svår att avgränsa då det är så pass integrerat med UI.) Skrivet 2023.

Sen angående sökning i stora kodbaser så bör väl koden struktureras upp och placeras i separata kataloger så att man redan från början har ett hum om var man skall börja leta. När jag dyker i linux-kärnan eller som just nu Firefox (ca 10 M rader kod, inkl kommentarer, exklusive include-filer, grovt räknat!) så finns det jag letar efter väl samlat i ett par delkataloger. Letar jag vidare efter procedurer eller variabler så stannar ju sökningarna inom dessa kataloger med hjälp av "grep | less".

Det som brukar hjälpa mig är att skapa en call-graph över applikationen, då får man en översikt över hur det hela hänger ihop.

klk: När du jobbar med HN är inte ägarskapet (ursprung) viktigare än typen? Jag skulle kunna tänka mig att om man har flera externa variabler (globaler) så kan man t.ex. namnge dem som eCustomer eller gCustomer. I mina småhack så namnger jag lokala procedurer som app_* och om de kommer från något externt bibliotek (bench.a) som bnc_* exempelvis. Aldrig någon tvekan om var jag hittar källkoden då.

Det jag (vi?) gissar att "överlagring" refererar till här är polymorfism. Det är en viktigt komponent i OOP, men det är absolut inte bundet till OOP utan det är bara en komponent av många som används där. Clojure är inte alls OO, men där har man extremt flexibel modell för överlagring, går att göra på typ men även specifika värden för en typ.

Python har ju överlagring för klassmetoder precis som C++. Ovanpå det kan man ju använda "duck-typing" där, lite likt hur man kan göra statisk överlagring i C++ via template men skillnaden att i Python blir det ett runtime-fel om metoden man anropar inte finns på typen medan det i C++ blir ett kompileringfel. Både Rust och Go kan göra motsvarande (och en rad andra språk också).

C++ vtable
struct Animal {
    virtual ~Animal() = default;
    virtual void makeSound() const = 0;
};

struct Dog : Animal {
    void makeSound() const override { std::cout << "woff\n"; }
};
struct Duck : Animal {
    void makeSound() const override { std::cout << "quack\n"; }
};

int main() {
    std::vector<std::unique_ptr<Animal>> zoo;
    zoo.emplace_back(std::make_unique<Dog>());
    zoo.emplace_back(std::make_unique<Duck>());

    for (auto& a : zoo) a->makeSound();
}

C++ templates
struct Dog { void makeSound() const { std::cout << "woff\n"; } };
struct Duck { void makeSound() const { std::cout << "quack\n"; } };

template <class T>
void speak(const T& t) { t.makeSound(); }  // requires T has makeSound()

int main() {
    Dog d; Duck k;
    speak(d);
    speak(k);
}


Rust traits
trait Animal {
    fn make_sound(&self);
}

struct Dog;
struct Duck;

impl Animal for Dog  { fn make_sound(&self) { println!("woff"); } }
impl Animal for Duck { fn make_sound(&self) { println!("quack"); } }

fn main() {
    let zoo: Vec<Box<dyn Animal>> = vec![Box::new(Dog), Box::new(Duck)];
    for a in &zoo { a.make_sound(); }
}


Rust generics
trait Animal {
    fn make_sound(&self);
}

struct Dog;
struct Duck;

impl Animal for Dog  { fn make_sound(&self) { println!("woff"); } }
impl Animal for Duck { fn make_sound(&self) { println!("quack"); } }

fn speak<T: Animal>(t: &T) { t.make_sound(); }

fn main() {
    let d = Dog; let k = Duck;
    speak(&d);
    speak(&k);
}


Go interface
type Animal interface {
	MakeSound()
}

type Dog struct{}
type Duck struct{}

func (Dog) MakeSound()  { fmt.Println("woff") }
func (Duck) MakeSound() { fmt.Println("quack") }

func main() {
	zoo := []Animal{Dog{}, Duck{}}
	for _, a := range zoo {
		a.MakeSound()
	}
}


Go "static" style
type Speaker interface {
	MakeSound()
}

type Dog struct{}
type Duck struct{}

func (Dog) MakeSound()  { fmt.Println("woff") }
func (Duck) MakeSound() { fmt.Println("quack") }

func Speak[T Speaker](t T) { t.MakeSound() }

func main() {
	Speak(Dog{})
	Speak(Duck{})
}


Python
class Animal:
    def make_sound(self):
        # "virtual" method
        raise NotImplementedError("Subclass must implement make_sound()")

class Dog(Animal):
    def make_sound(self):
        print("woff")

class Duck(Animal):
    def make_sound(self):
        print("quack")

zoo: list[Animal] = [Dog(), Duck()]

for animal in zoo:
    animal.make_sound()   # Calls the appropriate override

Som sagt, svårt att säga exakt givet att Windows är closed-source. Men givet din 50M siffra tror jag du hittat samma referens som jag gjorde. Notera att 50M är totala mängden SLOC för ett komplett Windows 10 server OS, d.v.s. både kernel och det userland som är inkluderat. Koden för kärnan är en rätt liten del av det.

Linux är en kärna, Ubuntu är ett Linux-baserat OS så är i så fall det senare man skulle jämföra med (i en grundläggande installation).

Det vore högst märkligt om Windows-kärnan som den ser ut hos Microsoft skulle ha fler SLOC än Linux givet att en förkrossande majoritet av koden i Linux är drivers. Windows har drivers för en del grundläggande saker, men majoriteten av drivers kommer där i binärform från 3:e-part.

En OS-kärna består typiskt av relativt lite kod. Dels är det inte supermånga funktioner man har i en OS-kärna, grovt är 1/3-del schemaläggning, interrupt-hantering, systemanrop etc (i.e. core-core), 1/3-del är filsystemhantering och 1/3 del nätverksstacken.

Majoriteten av OS-kod är systembibliotek och systemtjänster, alla ligger i user-land om man inte har en totalt idiotisk design alt. det är ett embedded-OS där allt ligger i samma adressrymd.

"Korkade" saker i Windows som registret och liknande ligger inte i kärnan. Vidare är Windows-kärnan en hybridkärna, så den har i alla fall potential att ha mindre delar i kernel-space än en traditionell monolitisk kärna som Linux (tror Windows sedan länge har ljud, USB och lite mer out-of-kernel).

Sen består även vissa drivers allt mer av user-land kod. En modern GPU-driver har väldigt lite av koden körandes i kärnan, alla avancerade funktioner ligger numera i user-land. Det är förklaringen till varför saker som PyTorch med CUDA-acceleration presterar i stort sett lika bra under WSL2 som under "native" Linux. Att Linux kan vara upp till dubbelt så snabb här kommer av skillnader i user-land, WSL2 använder Windows-drivers för kernel-delen och Linux-drivers för user-land delen.

Jag vill backa diskussionen till HN igen. Jag förstår inte varför du envisas med att ställa HN och strikta regler för namngivning mot kaoset som uppstår när "man ... får namnge saker till vad man känner för". Även inom HN finns det en del av namnet, mellan prefix och eventuellt suffix som skall förmedla intent. Det styrs väl inte av HN utan utvecklaren kan välja själv här? Om någon av dina kollegor skulle få för sig att plocka slumpvisa ord ur ordlistan, säg gurka, volvo, sjöstjärna, hur mycket är du då behjälpt av att de i HN istället heter pGurka, uVolvo eller dSjöstjärna?

Är det så i din föreställningsvärld, att team som inte kör HN enkom består av ett gäng med sopprötter som medvetet kommer välja namn som gurka, volvo, och sjöstjärna för sina vektorer med kunddata, prislistor och filpekare? Och dessutom ta ett annat namn i nästa funktion? Varför skulle det automatiskt bli rörig namngivning bara för att man inte kör HN?

Lek med tanken att även medelbegåvade utvecklare väljer variabelnamn så de sammanfaller med den terminologi som gäller för domänen de jobbar med. Teamet har dessutom regler för hur namngivningen skall göras (style guide?), vad som ska förkortas och vad som inte ska förkortas, vilka standardavsteg som finns från namngivning, typ att loopvariabler får heta i, j, k, och att folk följer den etablerade stilen i projektet. Då ser jag inga som helst fördelar med HN. På vilket blir det bättre av att variabeln heter pSomething istället för something? Ja, du kan redan i sökningen skilja på pekare till something och vektorer eller listor av something, men det är väl ändå something som är det väsentliga och det du kommer söka på om du letar efter kod som hanterar something (ersätt something med en etablerad term som förekommer i er kod)?

Jag vet redan att du tycker HN är bättre och att du tycker att det blir lättare att hantera och söka i stora projekt, så det behöver du inte berätta en gång till. Jag är nyfiken på vad som gör det bättre, vad ser du för konkreta fördelar gentemot att inte ha typprefix på variablerna? Hur blir du hjälpt? I vilka fall blir det mycket bättre med HN?

C++ vtable
struct Animal {
    virtual ~Animal() = default;
    virtual void makeSound() const = 0;
};

struct Dog : Animal {
    void makeSound() const override { std::cout << "woff\n"; }
};
struct Duck : Animal {
    void makeSound() const override { std::cout << "quack\n"; }
};

int main() {
    std::vector<std::unique_ptr<Animal>> zoo;
    zoo.emplace_back(std::make_unique<Dog>());
    zoo.emplace_back(std::make_unique<Duck>());

    for (auto& a : zoo) a->makeSound();
}

C++ templates
struct Dog { void makeSound() const { std::cout << "woff\n"; } };
struct Duck { void makeSound() const { std::cout << "quack\n"; } };

template <class T>
void speak(const T& t) { t.makeSound(); }  // requires T has makeSound()

int main() {
    Dog d; Duck k;
    speak(d);
    speak(k);
}


Rust traits
trait Animal {
    fn make_sound(&self);
}

struct Dog;
struct Duck;

impl Animal for Dog  { fn make_sound(&self) { println!("woff"); } }
impl Animal for Duck { fn make_sound(&self) { println!("quack"); } }

fn main() {
    let zoo: Vec<Box<dyn Animal>> = vec![Box::new(Dog), Box::new(Duck)];
    for a in &zoo { a.make_sound(); }
}


Rust generics
trait Animal {
    fn make_sound(&self);
}

struct Dog;
struct Duck;

impl Animal for Dog  { fn make_sound(&self) { println!("woff"); } }
impl Animal for Duck { fn make_sound(&self) { println!("quack"); } }

fn speak<T: Animal>(t: &T) { t.make_sound(); }

fn main() {
    let d = Dog; let k = Duck;
    speak(&d);
    speak(&k);
}


Go interface
type Animal interface {
	MakeSound()
}

type Dog struct{}
type Duck struct{}

func (Dog) MakeSound()  { fmt.Println("woff") }
func (Duck) MakeSound() { fmt.Println("quack") }

func main() {
	zoo := []Animal{Dog{}, Duck{}}
	for _, a := range zoo {
		a.MakeSound()
	}
}


Go "static" style
type Speaker interface {
	MakeSound()
}

type Dog struct{}
type Duck struct{}

func (Dog) MakeSound()  { fmt.Println("woff") }
func (Duck) MakeSound() { fmt.Println("quack") }

func Speak[T Speaker](t T) { t.MakeSound() }

func main() {
	Speak(Dog{})
	Speak(Duck{})
}


Python
class Animal:
    def make_sound(self):
        # "virtual" method
        raise NotImplementedError("Subclass must implement make_sound()")

class Dog(Animal):
    def make_sound(self):
        print("woff")

class Duck(Animal):
    def make_sound(self):
        print("quack")

zoo: list[Animal] = [Dog(), Duck()]

for animal in zoo:
    animal.make_sound()   # Calls the appropriate override

Jag skulle hävda att detta är exempel på "överskuggning" (eng. overriding), dvs då en subtyp omdefinierar en metod definierad av en supertyp.

När det kommer till "överlagring" (eng. overloading) så handlar det om att ge samma namn till olika operationer, och det har inte nödvändigtvis någonting med typhierarkier att göra alls. Vad som händer är kontextuellt, där kontexten i sig kan te sig på olika sätt. Ett praktexempel är att det är funktionsargumenten som ger kontexten, ex. genom att ha olika mängd argument eller olika typer på argumenten (se exempel i Java nedan).

public class Adder {
  public static void main(String[] args) {
    System.out.println(add(1, 2)); // 3
    System.out.println(add(1, 2, 3)); // 6
    System.out.println(add("1", "2")); // "3"
  }

  public static int add(int lhs, int rhs) {
    return lhs + rhs;
  }

  public static int add(int a, int b, int c) {
    return a + b + c;
  }
  
  public static String add(String lhs, String rhs) {
    return String.valueOf((Integer.parseInt(lhs) + Integer.parseInt(rhs)));
  }
}

Min uppfattning är att dessa definitioner är vedertagna, och stöds även av Wikipedia-artiklarna på overloading och overriding. Jag lärde ut detta i många år på KTH och det fanns en konsensus inom fakulteten att detta är hur dessa ord ska användas.

Det är dock möjligt att de svenska termerna är lite mer flytande, vi har minst sagt haft lite problem med terminologi i svenskan vad gäller programmering.

Hur mycket tillför detta till nuvarande snurr i denna tråd? Oklart. Antagligen ingenting. Men jag kände ett behov av att förtydliga dessa ofta ihopblandade termer.

Jag håller med jag tolkar överlagring som overloading som i function overloading. Det hjälper dock inte diskussionen om vad @klk egentligen menar eftersom jag redan frågat @klk om det är funtion overloading som han syftar på när han säger "överlagring".

Här frågar jag och fick följande som svar...

Jag har aldrig sagt något om OOP utan har frågat dig om det är function overloading utan att få något svar. Jag har t o m uppmuntrat dig att läsa Wiki-sidan istället ger du osammanhängande förklaringar som är långt ifrån function overloading som telefonkatalogsexemplet.

Det var samma inlägg som jag sa att ditt telefonkatalogsexempel inte beskriver functional overloading... Trots det försökte du dig på att dra samma exempel mot @Yoshman en andra gång istället för att ge en teknisk förklaring på vad du egentligen menar ...

@klk

Vidare gällande functional overloading...

Om du hade beskrivit det i stil med "att deklarera samma funktion med olika parametrar" istället för:

Då hade nog alla varit med på vad du menar ...

Alltså ... du använde termen överlagring på ett sätt som inte passade sammanhanget. Jag kontrollfrågade vad du menar med överlagring och frågade om det var functional overloading. Vid detta tillfället kunder du bara googlat och sagt ja/nej eller gett ett kodexempel. Istället så säger du det med telefonkatalogen som inte har något att göra med något vi pratat om ...

Man behöver ju inte vara någon Shakespeare för att skriva ja/nej eller posta ett relevant kodexempel.

Nu förstår jag inte vad du menar igen. Hur gick vi från overloading till mönster?

All kod är någon form av mönster, så utvecklare är definitivt vana vid att koda i mönster som skapas av uppgifterna vi löser och språkkonstruktionerna vi använder.

Nu förstår jag inte vad du menar igen. Hur gick vi från overloading till mönster till vad chefen tycker till vad du anser om hack?

"override" är för mig specifikt fallet där en subtyp definierar om / lägger till till något som redan är definierat av en supertyp.

Men det är långt ifrån alla varianter av runtime-polymorfism och för mig sin ganska sällan använder OOP är det en rätt ovanlig användning.

Dynamisk polymorfism är ju oftast bara att olika typer (och potentiellt olika andra selektorer, t.ex. värde i Clojure) avgör hur en viss metod hanteras.

public class Adder {
  public static void main(String[] args) {
    System.out.println(add(1, 2)); // 3
    System.out.println(add(1, 2, 3)); // 6
    System.out.println(add("1", "2")); // "3"
  }

  public static int add(int lhs, int rhs) {
    return lhs + rhs;
  }

  public static int add(int a, int b, int c) {
    return a + b + c;
  }
  
  public static String add(String lhs, String rhs) {
    return String.valueOf((Integer.parseInt(lhs) + Integer.parseInt(rhs)));
  }
}

Det är en form av överlagring. Just ditt exempel hade lika väl kunna hanteras med en variadic funktion och då hantera godtyckligt antal argument av en viss typ.

Den här typen av polymorfism verkar inte gillas av alla. Vissa moderna språk, som t.ex. Go och Rust väljer ju att INTE stödja detta.

Sen är inte heller detta den enda formen av compile-time polymorfism. C++ templates gör ju sådana val compile-time (Rust har liknade funktionalitet)

Så att bara säga "överlagra" är inte i närheten tillräckligt exakt för att man ska förstå vad som menas!

Ett team består inte bara av programmerare, en del är interaktionsdesigners (som absolut inte ska skriva kod, de är ofta ganska kassa på det, i alla fall är det min erfarenhet), andra är systemarkitekter (som inte heller ska koda), minst en har till uppgift att samordna övrigas verksamhet och sen har vi programmerarna (som inte ska göra annat än koda och dokumentera koden, absolut inte lägga sig i designers och arkitekters jobb).
Det är min erfarenhet men det finns naturligtvis de som kan ha gränsöverskridande verksamhet. Ta mina kommentarer inom parenteser med ett par nypor salt

Det är exakt vad Python-koden i ditt exempel gör, och jag erkänner att jag stirrade mig lite blind på just den delen. Jag medger att det pattern som används härmar interfaces i andra språk, men Python's runtime saknar interfaces och detta är i praktiken överskuggning sett till hur iaf CPython kommer utvärdera anrop till metoden.

Vi kanske talar om varandra. Jag tolkade som att du i ditt inlägg menade att alla exempel demonstrerade överlagring eftersom spoilern löd "trivial exempel med överlagring i C++, Rust, Go och Python", men baserat på detta uttalande kanske du helt enkelt bara demonstrerade polymorfism? Det har jag inga invändningar mot, det är absolut polymorfism alltihop.

Jag är heller inte av uppfattningen att implementering av interfaces/traits är något som generellt definieras som överlagring. Om vi tar Go som exempel har till och med dess FAQ en sektion som talar om varför språket inte stödjer överlagring. Polymorfism? Absolut. Men överlagring? Det har jag svårt att se att många skulle tolka det som, även om jag till viss del håller med om att det skulle kunna passa in rent definitionsmässigt ("kontexten" för överlagringen blir den konkreta typen).

Jag tror att du missade den sista metoden som tar strängar istället för ints. Det går inte generellt att hantera med variadics. Och även om det skulle gå hävdar jag ändå att detta är typexempel på (funktions/metod)överlagring. Att andra tekniker kan uppnå samma sak (generics, till exempel) gör inte att detta blir mindre överlagrat.

Den andra välkända formen av överlagring är operatoröverlagring, som om något är ännu mer omtvistat än funktionsöverlagring. Men principen är exakt densamma.

Innan denna diskussion skulle jag säga att det är fullt tillräckligt! Att bara säga "överlagra" är i min mening starkt indikativt att personen avser funktions- eller operatoröverlagring, givet att denne har ett hyggligt grepp om programmering, och kontexten borde avslöja resten. Men då jag anser att du är en högst påläst och kunnig person så får jag helt enkelt medge att det inte är tillräckligt, denna diskussion är ju inget annat än skriftligt bevis för det. Iallafall inte när kontexten är såpass lösryckt som den är här.

Nu har jag nog gjort mitt i att gå på side quests i denna tråd. Jag tror vi eventuellt får "agree to disagree".