650 likes | 741 Views
Engineering Classes Version 1.1. Objectives. At the conclusion of this lesson, students should be able to: Explain how to correctly write class declarations and implementations. Explain why it is important to correctly manage dynamically allocated storage.
E N D
Objectives At the conclusion of this lesson, students should be able to: Explain how to correctly write class declarations and implementations. Explain why it is important to correctly manage dynamically allocated storage. Write programs that correctly use * Destructors to return dynamically allocated storage to the system. * Overloaded assignment operators to make a deep copy when necessary and return dynamically allocated storage to the system. * Copy constructors to make a deep copy when necessary.
To design your own classes • Define the class in the .h file • class Data { private: //declare data public: //declare function prototypes }; //end class Data
Design your functions in .cpp file • Data::Data(void){ //body } //default constructor • Data::Data(int x}{ //body } //parameterized consts • Data::~Data(void){ //body } //destructor • double Data::DoSomething(double y){ //body } • void Data::Stuff(void){ //body }
Memory Management One of the major program design issues in C++ is memory management. The mishandling of dynamically allocated storage in C++ is among the most serious programming errors made when using the language. Many of these issues can be addressed by designing classes as Concrete Data Types.
Concrete Data Types One of the goals of good software development in C++ is to construct each class so that it appears, to the applications programmer, to be equivalent to a built-in type for the language. That is, it is well behaved in all of the ways that a standard built-in data type is well behaved. A C++ class written in this way has been termed a “concrete data type''. Although in detail, the implementation of a class is specific to the class, all concrete data types have a similar structure. Some author’s refer to this structure as the orthodox canonical class form.
local variables size and amount known at compile time global and static variables Review C++ Programs can allocate objects in one of three memory areas. The run-time stack The static data area or data segment The heap or free store storage allocated at run-time because we don’t know how much or what type of data will be stored when the program is compiled.
An object is allocated on the heap using the new operator. The allocated object has no name, but is referenced through a pointer returned by the new operator. Storage allocated using new must be recycled back to the heap when the storage is no longer required. Storage that is no longer accessible, but has not been returned to the heap is called a memory leak.
Un-initialized pointers should be set to NULL. Pointers should also be set to NULL after calling delete to return storage to the heap.
Destructors All Concrete Data Types must have a destructor if it manages resources through a pointer. When program execution reaches the end of a block in which an object was declared, the storage allocated for that object on the stack is relinquished. If a destructor is defined for the class to which the object belongs, the destructor is called first. The purpose of the destructor is to clean up any resources that the object may have acquired. The most common resource that needs to be managed is storage allocated from the heap.
Linked Lists The concepts discussed in this slide set will be illustrated using a linked list. Before going through the examples, it will be necessary that you understand what a linked list is and how they are used. This should be a review of the material presented several weeks ago.
Memory Issues node node node 3 12 7 list 9 null This diagram illustrates an example of a linked list. In this example, each node of the list is dynamically allocated from the heap and contains an integer value and a pointer to the next node in the list.
node node node 3 12 7 list 9 null class List { private: Node* head; int length; public: . . . }; the List class just contains a pointer to the first node in the list, and an integer containing the number of elements in the list.
node node node 3 12 7 list 9 null class Node { private: int data; Node* next; public: Node* getNext( ); … }; Each node object contains an integer data member and a pointer to the next node. The storage for each node is allocated from the heap as it is needed.
3 list node node node 12 7 9 null So … what happens in this case when the list object goes out of scope? With no destructor, the pointer data member in the list object is relinquished when the object goes out of scope. Without this pointer, the first node, and all subsequent nodes, become inaccessible to the program. Since the storage for these nodes is still owned by the program, we have a memory leak. some block { List myList; . . . blah … blah … blah . . . }
3 list node node node 12 7 9 null Can you come up with a destructor that keeps The memory leak from happening?
3 list node node node head length 12 7 9 null data next List::~List { }
3 list The following destructor will solve the problem. node node node head length 12 7 9 null data next List::~List( ) { delete next; }
calls destructor 3 list node node node head length 12 7 9 null data next List::~List( ) { delete next; } this makes a recursive call to the next destructor
desrtructor pending calls next destructor node 3 12 list data next node node head length 7 9 null List::~List( ) { delete next; } this is getting boring as we recurively call the destructors
delete on null = nop 3 list destructors pending node node head length 7 9 null List::~List( ) { delete next; } will this never stop recusively calling?
delete on null = nop 3 list destructors pending node node head length 7 9 null List::~List( ) { delete next; } will this never stop recusively calling? destructor completes
delete on null = nop 3 list destructor pending node node head length 7 9 null List::~List( ) { delete next; } will this never stop recusively calling? destructors complete
delete on null = nop 3 list node node head length 7 9 null List::~List( ) { delete next; } will this never stop recusively calling? destructors complete list.head = NULL;
Assignment Operator We just illustrated how to manage the memory allocated dynamically for Node objects when the list goes out of scope. However, the automatic invocation of the destructor when the object goes out of scope introduces another serious problem. Consider the following …
node node node list_a 3 12 7 list 9 null node node list_b 2 21 6 list null
list_a = list_b; Problem: The pointer to this Data has been lost. Memory Leak! node node node list_a 3 12 7 list 9 null node node list_b 2 2 21 6 list null the default assignment operator does a member-by member copy of each data member in the list objects.
Now … suppose list_b goes out of scope. node node node list_a 2 12 7 list 9 null node node Problem: the pointer in list_a points to memory no longer owned by the program. list_b 2 21 6 list null Our destructor, as specified, cleans up the list, returning the storage for each node to the heap.
Adding insult to injury, what happens when list_a goes out of scope? node node node list_a 2 12 7 list 9 null this storage gets returned twice! This could totally destroy the memory manager! Storage belonging to the heap.
We solve this problem by overloading the assignment operator in the List class. The assignment operator must do two things: list_a = list_b; Free the storage used by the left operand (list_a) Make a copy the entire data structure of the right operand (list_b) and point to it in the left operand -– do a deep copy.
Free this storage node node node list_a 3 12 7 list 9 null node node list_b 2 21 6 list null
node node 21 6 null list_a 2 3 list node node list_b 2 21 6 list null Make a copy the entire list …
it is customary to name the parameter ‘b’ return a List reference to allow multiple assignment always pass the operand as a constant reference const List& List::operator=(const List& b) { if (this ==&b) return *this; first, check to make sure that we are not doing the assignment a = a; We don’t want to clean up storage for a if this is the case.
const List& List::operator=(const List& b) { if (this ==&b) return *this; Node* p = head; while (p != NULL) { Node* pnext = p->getNext( ); delete p; p = pnext; } this code cleans up the storage allocated to the left hand list. Note: It’s the same code we wrote for the destructor.
Next, we are going to do the copy. We are going to do what is called a deep copy. That is, we are going to create a complete copy of the data structure that is on the right hand side. A shallow copy only copies pointers, not what they point to.
start by copying the length data. set the Node* p to Null, we will use this later. length = b.length; p = NULL; Node* q = b.getHead( ); while (q != NULL) { Node* n = new Node; n->setNext (NULL); n->setData (q->getData( )); if (p == NULL) head = n; else p->setNext (n); p = n; q = q->getNext ( ); } return *this; then declare another Node* q, and set it to the head data member in list b.
length = b.length; P = NULL; Node *q = b.getHead( ); q list_a n p NULL list node node list_b 2 2 21 6 list
length = b.length; p = NULL; Node* q = b.getHead( ); while (q != NULL) { Node* n = new Node; n->setNext (NULL); n->setData (q->getData( )); if (p == NULL) head = n; else p->setNext (n); p = n; q = q->getNext ( ); } return *this; Now, allocate storage for the first node in the new list. set its pointer to the next node to NULL. get the data member of the current node in the right-hand list and store its value in this new node.
Node *n = new Node; n points to the new node just created q NULL list_a n 2 p NULL list q points to the current node in the right hand list node node list_b 2 21 6 list n -> setNext (NULL); n -> setData (q.getData( ));
length = b.length; p = NULL; Node* q = b.getHead( ); while (q != NULL) { Node* n = new Node; n->setNext (NULL); n->setData (q.getData( )); if (p == NULL) head = n; else p->setNext (n); p = n; q = q->getNext ( ); } return *this; If this is the first node store its pointer in the list object.
if (p == NULL) head = n; q head NULL 21 list_a n 2 p NULL list node node list_b 2 21 6 list
length = b.length; p = NULL; Node* q = b.getHead( ); while (q != NULL) { Node* n = new Node; n->setNext (NULL); n->setData (q.getData( )); if (p == NULL) head = n; else p->setNext (n); p = n; q = q->getNext ( ); } return *this; set to point to the end node in left hand list, the one we just created set to point to the next node in the right hand list.
p = n; q = q->getNext( ); q head NULL 21 list_a n 2 p list node node list_b 21 2 6 list
We have copied the List Object and the first Node. Since q is not null (it points to a node) go through the while block again.
list_a = list_b; q head NULL list_a 21 n 2 NULL p list node node list_b 21 2 6 list Node* n = new Node; n->setNext (NULL); n->setData (q.getData( ));
list_a = list_b; q head list_a 21 n 2 NULL 6 p list node node NULL list_b 21 2 6 list else p->setNext (n); p is not null, so … p = n; q = q->getNext ( );
We have successfully copied the second node from the right-hand list. q is now = NULL, so we drop out of the loop.
Copy Constructor We have fixed the assignment operator so that is correctly creates a copy of the object. However, objects also get copied when passed by value. When a function is called, all of the function arguments are copied into local variables associated with the function. When the function exits, these variables go out of scope and are destroyed. This will cause similar problems to the ones we just discussed with the default assignment operator.
node node node 3 12 7 list_a 9 Consider the list shown. What happens in the function invocation double average (List a);
3 node node node 3 12 7 list_a 9 when the function is called, a copy of the list object goes on the stack. The default is a shallow copy …. stack