3. Minneshantering - (copy)konstruktorn, destruktorn och tilldelningsoperatorn

3. Minneshantering - (copy)konstruktorn, destruktorn och tilldelningsoperatorn Minneshantering har väldigt lite med objektorienterad programmering att göra, många objektorienterade programspråk implementerar en skräpsamlare som tar hand om minne som inte används längre. I C++ finns dock ingen sådan skräpsamlare p g a effektivitetskrav. Därför krävs att en C++-programmerare känner till lite om minneshanteringen för att kunna implementera robusta klasser. Ett C++-program kan allokera minne i tre minnesområden: Run-time-stacken (Automatic storage) Statiska minnet (Static storage) Heapen eller fritt/dynamiskt internminne (Free storage, Heap memory, Dynamic memory) Dessa minnestyper har olika semantik vad gäller objekts initiering och livstid. Lokala objekt/variabler som definieras per värde inuti operationer och operationsargument (vid värdeanrop) allokeras på run-time stacken. Objekt skapas automatiskt på stacken vid ingång i en operation eller ett block Vid utgång ur ett block tas inte värdena bort rent fysiskt på stacken utan stackpekaren flyttas helt enkelt för att möjliggöra överskrift av nya stackvariabler. Globala objekt/variabler, statiska objekt/variabler, statiska datamedlemmar i en klass, och namespace variabler allokeras i det statiska minnesområdet. Stacken och det statiska minnesområdet används för att allokera data vars storlek är känd vid kompileringen. På heapen allokeras minne dynamiskt, i C++ med hjälp av nyckelordet new. Ex: Object* o = new Object(possibly constructor arguments ); Minne som allokerats dynamiskt måste lämnas tillbaka manuellt av programmeraren med nyckelordet delete. delete o; Heapen upprätthåller en lista av de minnesblock med respektive storlekar som är fria för allokering. Denna information är lätt att förstöra, exempelvis genom att skicka en adress till delete som ej fåtts genom allokering med new eller att göra delete två gånger på samma pekarvariabel eller genom att fortsätta skriva till ett minnesblock efter att det återtagits med delete

3.1 Konstruktorer Varje klass har fyra speciella medlemsoperationer: defaultkonstruktorn, copy-konstruktorn, destruktorn och tilldelningsoperatorn. Om dessa inte explicit deklareras och definieras av programmeraren så genereras de implicit. Meningen med konstruktorer är att dessa skall initiera varje datafält i objektet. Varje klass skall ha minst en konstruktor, och många bör också ha en defaultkonstruktor. Det är mycket vanligt att det finns flera konstruktorer definierade för en klass. När ett objekt allokeras reserveras minne för det. Vid detta tillfälle har objektet inga väldefinierade data. Objektets fält innehåller värden som råkar vara kvarlevor av tidigare programaktivitet. Det är konstruktorns jobb att initiera objektets datafält. En defaultkonstruktor kännetecknas genom att den inte tar emot några argument. Om programmeraren inte explicit deklarerar någon konstruktor alls så genereras en defaultkonstruktor implicit om klassen inte innehåller konstanter eller referenser som datamedlemmar. Viktigt att komma ihåg är också att defaultkonstruktorn inte utför någon initiering av användardeklarerade datamedlemmar eller allokering av dynamiskt minne. Då man har deklarerat en konstruktor som tar en eller flera parametrar så genereras ej en defaultkonstruktor implicit. Vill man då ha en defaultkonstruktor måste denna deklareras explicit. Detta illustreras av kodexemplet nedan. class File public: File(const string& file_path, int open_mode); ~File(); private: string path; int mode; ; File folder1[10]; //error, array requires default constructor File folder2[2] = File("f1", 1); // error, folder2[1] still requires // a default constructor File folder3[3] = File("f1", 1), File("f2",2), File("f3",3) ; //OK, fully initialized array

Explicita Konstruktorer En konstruktor som tar ett argument är default en implicit konverteringsoperator. Denna konverterar dess argument till ett objekt av sin klass. class String public: String(); String(int size); // constructor and implicit conversion operator String(const char* s); // constructor and implicit conversion // operator ~String(); private: int size; char *buffer; ; Att konvertera en int till en sträng är inte vettigt, detta är dock vad som händer nedan. int main() String s = "hello"; //OK, convert a C-string into a string object int ns = 0; s = 1; // 1 oops, programmer intended to write ns = 1 // I uttrycket s = 1; har programmeraren gjort ett skrivfel. Normalt skulle kompilatorn klaga och ge ett fel. Innan detta sker så letar först kompilatorn efter användardefinierade konversioner som tillåter detta. Kompilatorn finner en konstruktor som tar en int, och tolkar därför skrivfelet enligt följande: s = String(1); Detta har den oönskade effekten av att det förra objektet går förlorat och variabeln s refererar nu till ett nytt objekt. Ett liknande problem kan uppstå då en operation anropas som tar ett string-objekt som argument. int f(string s); int main() f(1); // without an explicit constructor, //this call is expanded into: f ( String(1) ); //was that intentional or merely a programmer's typo? För att undvika dessa implicita typkonversioner som ger en otydlig semantik måste konstruktorer som tar ett argument deklareras som explicit.

class String public: explicit String(int size); // block implicit conversion String(const char* s); //implicit conversion still possible ~String(); //... ; int main() String s = "hello"; //OK, convert a C-string into a string object int ns = 0; s = 1; // compile time error ; this time the // compiler catches the typo Varför är inte alla konstruktorer automatiskt deklarerade som explicit? Ett bra exempel på varför är string-klassens tredje konstruktor. String(const char *); String s; s = "Hello"; Denna tilldelning är tämligen semantiskt och intuitivt bra. Kompilatorn konverterar detta implicit till: s = String ("Hello"); //create a temporary and assign it to s Om denna konstruktor deklareras explicit måste man göra en typkorrekt tilldelning. class String public: explicit String(const char* s); //... ; int main() string s; //s = "Hello"; //does not work anymore s = string("hello"); //explicit assignment now required return 0; Det rekommenderas starkt att alltid deklarera en konstruktor som tar ett argument som explicit. Då tvingas alla som använder denna klass att förstå vad de håller på med samtidigt som man tar bort risken att skrivfel orsakar oönskade sidoeffekter.

3.2 Copy-konstruktorn En copy-konstruktors jobb är att av ett givet objekt skapa en kopia med skillnaden att det nya objektets identitet är skilt från originalobjektets. Copy-konstruktorer är användbara av följande anledningar. En uppenbar anledning till att ha copy-konstruktorer är för att direkt och explicit kunna göra en kopia av ett objekt. List a; // Make copies of List a List b(a) ; List* c = new List(a); En mer subtil anledning till att definiera en copy-konstruktor är att den behövs för att kunna kopiera argument och returvärden till/från operationer vid värdeanrop/värderetur. double average(list a) double sum = 0; int n = a.length(); //... return sum/n; Anmärkning: "a" är ett lokalt objekt i operationen average och ~List() anropas därför vid utträde ur operationen. int main() List lst; Double avg = average(lst); // lst copied into a Vad händer om vi inte har definierat en copy-konstruktor? 1. Om vi inte definierar en copy-konstruktor genereras en automatiskt och i denna sker en enkel kopiering av alla datamedlemmar. Alla variabler initieras (exempelvis, a.head = lst.head) 2. När operationen avslutas förstörs alla lokala varibler (för "a" anropas ~List() vilket tar bort alla noder i listan) 3. lst.head är därmed ej längre giltig. 4. Dessutom, när ~List() anropas för "lst" så kan det hända att delete appliceras på en ogiltig pekare vilket korrumperar listan över det fria minnet. Katastrofen är ett faktum. Anmärkning: Hur har ni klarat er utan en copy-konstruktor hittills? Jo, ni har använt er av alias, eller pekare. double average(list& a) //

double average(list* a) // Emellertid behöver man generellt alltid definiera en copy-construktor för att försäkra sig om ett korrekt beteende vid värdekopiering. Implementation av copy-konstruktorn List::List(const List& originallist) //Copy all the nodes in "originallist" to this list object När ovanstående har definierats så används copy-konstruktorn automatiskt för att kopiera argument till och returvärden från operationer. Alla klasser med en icketrivial destruktor behöver både en användardefinierad tilldelningsoperator och en användardefinierad copy-konstruktor. (Se nedan vad som menas med en icketrivial destruktor.) En del datastrukturer kan vara dyrbara att kopiera, genom att deklarera copy-konstruktorn och tilldelningsoperatorn som private ger kompilatorn ett felmeddelande om en användare av klassen försöker tillämpa en operation som kräver att dessa båda används. I detta fall behöver man givetvis inte implementera tilldelningsoperatorn eller copykonstruktorn utan bara deklarera dem. List reverse(list a) //"a" is made as a copy using the copy constructor List r; //... return r; // List (const List& originallist) copies r to the // scope of the caller // ~List destroys r List u, v; v = reverse(u); Om ingen användardefinierad copy-konstruktor existerar genereras en automatiskt. En implicit deklarerad copy-konstruktor är en public medlem i sin klass och har formen: C::C(const C&) ; Anmärkning: Detta gäller endast om varje eventuell basklass till C har en copy-konstruktor vars första argument är en konstant referens till ett objekt av basklassens typ Om detta inte är fallet kommer den implicit (automatiskt) definierade copy-konstruktorn att se ut på följande sätt: C::C(C&);

3.3 Destruktorn När man lämnar ett programblock i vilket ett objekt har allokerats återlämnas minnet till stacken. (Förutsatt att objektet allokerats på stacken). Har en destruktor deklarerats för klassen till vilken objektet hör så kommer destruktorn att exekvera innan minnet återlämnas till stacken. Uppgiften för en destruktor är att frigöra de resurser som objekt tagit i anspråk. De vanligaste uppgifterna för en destruktor är att återlämna minne, att stänga öppna filer, och att "släppa lås". Destruktorer anropas automatiskt och skall normalt sett inte anropas manuellt av programmeraren. Om man inte definierar en destruktor så genereras en automatiskt. Denna destruktor gör ingenting och ser ut som nedan. List::~List() Detta fungerar såvida inte man behöver frigöra resurser. För en länkad lista vet vi att det inte fungerar eftersom vi allokerar minne dynamiskt. Detta minne måste vi sedan avallokera i destruktorn. List::~List() //delete all the nodes in this list object Då vi har en destruktor som behöver utföra något speciellt kallas den för en icketrivial destruktor. Ta för vana att alltid definiera en destruktor för att undvika missöden.

3.4 Tilldelningsoperatorn En användardeklarerad (och definierad) tilldelningsoperator av en klass C är en icke statisk, medlemsoperation som tar exakt ett av argumenten C, C&, const C&, volatile C&, eller const volatile C& och returnerar C&. (Förutsatt en klass vid namn C.) Vi ska alltid använda en tilldelningsoperator som tar argumentet "const C&", vilket är normalfallet. Om ingen tilldelningsoperator har definierats av programmeraren skapas en implicit, denna är en public medlemsoperation av sin klass, och har formen: C& C::operator=(const C&); Tilldelningsoperatorn och destruktorer Destruktorers egenskap att anropas automatiskt innebär ett problem tillsammans med tilldelningsoperatorn såvida man inte har definierat den. List a: a.insert(...); //... List b; b.insert(...); //... a = b; // b goes out of scope // a goes out of scope // What happens? Två problem: De noder som listan a äger tas inte bort. De noder som listan b äger tas bort två gånger! Det första problemet uppstår vid tilldelningen, a = b, då sätts headpekaren i listan a att peka på det headpekaren i listan b pekar på. Därmed tappas alla noder bort som headpekaren för listan a refererade till. Listan b tas sedan bort första gången där det står; //b goes out of scope. Då b går ur scope körs ju destruktorn för b som avallokerar alla noder. När sedan a går ur scope, som ju refererar till de noder som tillhörde listan b, körs ju destruktorn för a och i värsta fall försöker då destruktorn att avallokera de noder som ju redan avallokerats då b gick ur scope. Då korrumperar man den lista som upprätthålls av systemet och som håller koll på det dynamiskt allokerade minnet. Katastrofen är ett faktum. Med den automatgenererade tilldelningsoperatorn sker endast en enkel tilldelning av datamedlemmarna. En lista har datamedlemmarna;

int size; Node* head; För tilldelningen med listobjekten ovan, a = b innebär detta följande; // OBS! Koden är ej korrekt utan används bara för att illustrera vad // som händer. a.head = b.head; a.size = b.size; För variabeln size är det ingen fara, den är av datatypen int och det vet vi ju att det går bra att tilldela en varabel av typen int till en annan. a.size blir en kopia av b.size. Däremot är det värre med den första tilldelningen. a.head = b.head innebär att a.head efter tildelningen pekar på samma sak som b.head, d v s a.head pekar på första noden i listan b. Vi måste alltså vid tilldelningen kunna se till så att: 1. de noder som a.head refererar tas bort på ett korrekt sätt 2. att a.head efter tilldelningen har fått en helt egen uppsättning noder vilka är kopior av noderna i listan b. Lösning Lösningen till detta problem heter att överlagra operatorer (operator overloading) som ger möjligheten att omdefiniera innebörden av operatorer för användardefinierade klasser. I detta fall vill vi överlagra operatorn = Låt oss titta på exemplet med listan igen för att förstå vad som händer List a: List b; a = b; //a = b; kommer av kompilatorn att översättas till a.operator=(b); Här ser vi att vad som sker är egentligen inget annat än ett operationsanrop. För listobjektet a anropas dess operation: List& operator=(const List& rhs);

Låt oss överlagra operatorn = för listan. class List public: List(); List(const List& originallist); ~List(); List& operator=(const List& rhs) //... private: Node *head; int size; ; List& List::operator=(const List& rhs) if(&rhs!= this) //delete all the nodes in this list object //copy all the nodes in rhs to this list object return *this; Några saker förtjänar att kommenteras. 1. Vad innebär, if(&rhs!= this)? 2. Vad innebär, return *this;? Först behöver vi klargöra vad this är, this är en pekare som finns i varje objekt och denna pekare refererar till sig själv. För ett listobjekt a, List a, refererar this-pekaren i a till a, alltså till sig själv. if(&rhs!= this) är därför ett skydd mot egentilldelning, d v s det är en kontroll av objektens identitet. Om någon gör följande; List a; a = a; kommer vi inte att utföra det som står inom if-satsen eftersom detta vore farligt. Varför är det farligt? Det bör du kunna lista ut. Denna kontroll mot egentilldelning måste alltid vara med då man definierar tilldelningsoperatorn. return *this; innebär att vi sist av allt returnerar objektet som ett alias. Att det returneras som ett alias ses av returtypen för tilldelningsoperatorn, den är List&. Detta ska göras för att möjliggöra kedjad tilldelning som innebär att fler än två objekt ingår i en kedja av tilldelningar.

List a: List b; List c; a = b = c; //Kedjad tilldelning Låt oss titta på vad som händer. Som ni redan vet sker tilldelning från höger till vänster, därför tilldelas först c till b (b = c). b.operator=(c); reslutatet av denna operation ska sedan tilldelas a, eftersom det är innebörden av att b tilldelas a (a = b). Men för att det ska gå att tilldela b till a måste ju, b.operator=(c); returnera något. Vad ska returneras? Jo, b självt, alltså this. Hela uttrycket a = b = c; översätts därför av kompilatorn till: a.operator=(b.operator=(c)); Alla klasser som har en icketrivial destruktor behöver en användardefinierad tilldelningsoperator. Anmärkning: Vi kommer i PUMA-kursen endast att titta på överlagring av operatorn = och ska inte göra en djupdykning i ämnet men det ska sägas att överlagring av operatorer generellt är en mycket kraftfull mekanism i C++. Många operatorer kan överlagras och ges en speciell innebörd. Den intresserade studenten rekommenderas att själv undersöka detta ämne djupare.

3.5 Gemensamma faktorer mellan copy-konstruktorn, destruktorn och tilldelningsoperatorn Implementationen av copy-konstruktorn, destruktorn och tilldelningsoperatorn har en hel del gemensamt. //Implementation av copy-konstruktorn List::List(const List& originallist) //Copy all the nodes in "originallist" to this list object //Implementation av destruktorn List::~List() //delete all the nodes in this list object //Implementation av tilldelningsoperatorn List& List::operator=(const List& rhs) if(&rhs!= this) //delete all the nodes in this list object //copy all the nodes in rhs to this list object return *this; Om du tittar på ovanstående implementationer så ser du att i copy-konstruktorn kopierar man noderna, i destruktorn tar man bort noderna och i tilldelningsoperatorn gör man bådadera. Två operationer, som ska vara privata medlemsoperationer, blir då uppenbara: void List::copy(const List& originallist) //copy all the nodes in "originallist" to this list object void List::free() //delete all the nodes in this list object

Implementationen av copy-konstruktorn, destruktorn och tilldelningsoperatorn blir då: List::List(const List& originallist) copy(originallist); List::~List() free(); List& List::operator=(const List& rhs) if(&rhs!= this) free(); copy(b); return *this; Anmärkning: De gemensamma faktorerna mellan copy-konstruktorn, destruktorn och tilldelningsoperatorn är inte specifika för en lista. Listan har använts som ett exempel för att ni är bekanta med denna. De gemensamma faktorerna gäller oavsett vilken klass ni implementerar. Utnyttja detta faktum! 3.6 Summering Varje klass har fyra speciella medlemsoperationer: default-konstruktorn, copy-konstruktorn, destruktorn och tilldelningsoperatorn. Om dessa inte explicit deklareras och definieras av programmeraren så genereras de implicit. Du måste alltid definiera en copy-konstruktor då du har en icketrivial destruktor. Du måste alltid definiera en tilldelningsoperator då du har en icketrivial destruktor. Alternativet är att inte tillåta kopiering och/eller tilldelning, detta kan du göra genom att deklarera copy-konstruktorn och/eller tilldelningsoperatorn som privata. (Detta är dock specialfall och ska användas med eftertanke och återhållsamhet.) Ta för vana att alltid definiera copy-konstruktorn, destruktorn och tilldelningsoperatorn, då kan du vara säker på att minneshanteringen går rätt till. Ta också för vana att definiera åtminstone en konstruktor, det behöver inte vara defaultkonstruktorn, det är inte alltid den är vettig att ha med i klassen.