Table of Contents

Things To Do with DATA

Things you should do before too much time passes:

EoCE errata

20131210

The original (incorrect) code in src/stack/size.cc is: 

int Stack :: getListSize()
{
    return (this -> getQuantity());
}

To fix it, note the addition of the reference to the data element between this and getQuantity(): 

int Stack :: getListSize()
{
    return (this -> data -> getQuantity());
}

It has been fixed in the provided code.

20131209

Without fully realizing this, I halfway did this in the stack and queue destructors (called delete, then set the pointer to NULL). However, I did not do this to the base pointer of the object (only to the data pointer and various node pointers). This left what appeared to be an “initialized” area of memory remaining, which I remember remarking to one person “it appears to be still allocated, but I suspect this is not permanent”, meaning it could well go away and lead to a segmentation fault sort of situation.

So, when interacting with the delete keyword and implementing destructors, remember that the pointer itself should be explicitly set to NULL for the most predictable and, in our case, safest operation.

I have updated any provided destructor code with a (hopefully) working solution… this includes src/node/destroy.cc, src/stack/destroy.cc and src/queue/destroy.cc; I have provided a copy of the src/stack/destroy.cc code here: 

#include "stack.h"
 
Stack :: ~Stack()
{
    delete this -> data;
    this -> data = NULL;  // here I subconsciously did the "right thing"- set data to NULL immediately after calling delete on it
    this -> size = 0;
    this -> top  = NULL;
    this = NULL;          // a possible means of establishing sane behavior. This needs testing; it may not work here in the destructor.
}
// NOTE: If the explicit "this = NULL;" line doesn't work, one will need to set the deleted pointer to NULL as an immediate next action.

Note that the List destructor has a bit more to it than the node, stack, and queue destructors– the List destructor is effectively our “clearList();” function from earlier implementations, so it should take care to “delete” and set to NULL each node present in the list.

Be sure you do not just set nodes equal to NULL without first de-allocating them with delete– if we don't mark them de-allocated before setting the pointers to NULL, that memory is now disconnected but still allocated, resulting in a MEMORY LEAK.

Trivia: if you call delete on a pointer but do not then set the pointer to NULL and instead go on using it (a pointer using memory marked for de-allocation), we have what is known as a “dangling pointer”. This can result in (in an unpredictable manner) segmentation faults.

20131205

Find the following line, which upon closer analysis reveals all that is happening is the next pointer is being overwritten (with the same value over and over again): 

tmp -> setNext(tmp -> getNext());

and replace it with: 

tmp = tmp -> getNext();

20131125

        Node * getStart();
        Node * getEnd();

I also provided a start.cc and end.cc in the src/list/ directory with the usual code skeleton I provided for other functions. Implementation should be obvious if you've made your way through the Node class implementation (hint).

Week NOW

Week 7

Week 6

Week 5

Week 4

Week 3

Week 2

Week 1