Hjälp mig loss ur C-träsket, tack

Hej !
Problemet är att du bara skrivit deklarationerna för dina medlemsfunktioner i klassen, dvs du har bara skrivit "mallarna" för hur de ska se ut utåt.
De kan inte fungera förrän du också skrivit själva koden till dem, så du har helt rätt i att dessAlder inte har någon koppling till dinSatt_Alder funktion.

Antingen skriver du koden direkt under alla funtioner som tex
void Satt_Alder(unsigned int Alder)
{
dessAlder = Alder;
}

eller så gör du det separat utanför classbeskrivningen som

void katt::Satt_Alder(unsigned int Alder)
{
dessAlder = Alder;
}

Vanligen brukar man lägga klassernas deklarationer (dvs det som ser ut som du skrivit) i en separat "header" fil som bör ha ändelsen .h
Sedan skriver man själva koden till medlemsfunktionerna i en .cpp fil som importerar denna headerfil (görs med kommandot #import "katt.h" överst om det är vad din headerfil heter.)

Sedan har det kanske inte direkt med din fråga att göra, men du säger att din klass ska vara private.
Att vara private är ingen egenskap du kan tilldela en fristående klass (när du läser vidare kommer du dock att stöta på att du kan göra en klass "private" för en annan klass i samband med arv av klasser).

Däremot är vissa delar av din klass private utåt och det är de delar som du skriver efter "private :"
Värt att notera är att allt i din klass är private som default. Glömmer du att skriva "public :" eller "protected :" så är alltså allt private. Detta är lätt att göra fel på som nybörjare.
Gör du däremot en sk "struct" istället för "class" så är det tvärtom, allt är public från början. Detta är det enda som skiljer en "struct" från en "class".

Jo, jag kände likadant när jag först började läsa C++. Något av det svåraste att förstå som nybörjare är (i allfall var det så för mig) vad som var nödvändigt att skriva för att allt skulle fungera och varför.

Och som sagt, så är det ju inte heller så superviktigt när det gäller små klasser och program att separera de där "mellanstegen" från själva koden till funktionerna.
Gör man däremot ett större projekt med klasser med många medlemsfunktioner så blir det svårt att få en överblick över vilka funktioner som finns att tillgå om de skrivs tillsammmans med all kod på många sidor.
Man kan se "mellanstegen" som ett interface för någon som ska använda klassen. Den som ska använda klassen vill snabbt se vad som finns, utan att kanske vilja bry sig om hur funktionerna fungerar "bakom skalet". Det är lite som på en mobiltelefon, dator, bil eller vad man nu kan tänka sig. Användaren vill veta hur prylarna används, men kanske inte hur de fungerar inuti.

Det där tankesättet underlättar enormt när man skriver större projekt och klasser behöver använda andra klasser. När man skriver koden till sådana projekt skulle det bli väldigt svårt om man hela tiden var tvungen att rota igenom en massa kod.

Men som sagt, för små program kan det ju kännas lite meningslös. Jag antar att poängen är att man ska lära sig att strukturera programmen på det sättet så att man sedan kan fortsätta med det i större program när det hela blir mer relevant.

Men C++ kräver inte att man separerar deklarationerna från definitionerna. Det går alldeles utmärkt att skriva dem på samma plats.
Däremot blir det mycket mer överskådligt om man separerar dem.

Ja, det var det jag menade, så vi tänkte nog på lite olika saker.

Beroenden mellan olika .cpp-filer löser man oftast genom att använda sig av .h-filerna som gränssnitt. Dvs om p1.cpp använder klasser från p2.cpp, så deklareras klasserna i p2.h som sedan inkluderas i p1.cpp.

Kompilatorn behöver inte veta om innehållet i p2.cpp när den kompilerar p1.cpp, varje .cpp-fil kompileras normalt sett individuellt till en objektfil. Det är sedan i länkningssteget som allting sys ihop till en komplett exekverbar binärfil.