Things you should do before too much time passes:

• In src/stack/size.cc, there is a typo in the getListSize() function, which will cause it to always return a value of 0. This can be corrected by referencing the list element contained a Stack object.

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.

• Less of a bug, more of an unexpected behavior– using delete on an allocated object doesn't seem to (at least immediately) deallocate memory, but instead seems to initialize it (sets any subelements to 0). From consulting various pages on the internet, it would appear the following is happening:
  • upon calling delete on an instantiated object, the allocated memory is more-or-less marked as deallocated and can return to the OS memory heap- but the pointer pointing to that memory is still in place. Therefore, it is recommended to set any pointer to NULL following a call to delete.

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.

• It was pointed out that my stock displayf(), in src/list/display.cc has a logical error resulting in an infinite loop. A one-line fix is in order.

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();

• I noticed an omission I made to the List struct- accessor functions for start and end pointers. I have updated list.h by adding the following 2 function prototypes to the public section of the header file:

        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).

• EoCE is now located at the bottom of your Opus. It is accessible only by you (and me). As such:
  • you MUST be logged in to the wiki to see it.
  • if it doesn't show up and you are logged in, try adding “?purge=true” (sans quotes) onto the end of the URL and load that.

• Stacks! We went over concepts, and started our implementation (push() on Wednesday).. I asked people to try their hand at implementing pop() and peek(). We will be going over pop() on Thursday.
• I put a copy of the code we worked on in class in the /var/public/data/fall2013/stacks/ directory on lab46.
• I also asked for some features to be implemented into your linked list (I suggested to use the doubly linked list, although it is by no means necessary):
  • add a qty variable (int) to your Linked List struct
  • update your linked list functions to appropriately update qty so it contains an accurate list count
  • add a mklist() function, in the spirit of create() on the knowledge assessments, and mkstack() in our stack implementation.
• Pointer Fun with Binky! http://www.cs.stanford.edu/cslibrary/PointerFunCBig.avi
  • Also available for other languages: http://cslibrary.stanford.edu/104/
• I resolved the compiler warnings as experienced with my pop() code- the sample code is now in place.

• Knowledge Assessment (Part 1)! Be sure you know your linked lists!
• Knowledge Assessment (Part 2)! Be sure you know your linked lists!

• Next week, there will be a “knowledge assessment check” to evaluate your competency (you HAVE been spending lots of time playing with this out of class, haven't you?) with respect to singly and doubly linked lists.
• Your DLLMENU program will utilize the generic use functions (ie no input or output, unless specifically called for, such as displayf()/displayb()).
• We will look to implement a doubly linked list library, so that we may move onto to linked list based stacks.
• To clarify things, I put together a project page for the Singly Linked List Menu (SLLMENU).
• I also put together a project page for the Doubly Linked List Menu (DLLMENU).
• The day is getting closer; closer to getting your FreeCell-based Card Game Project completed (still need libraries and stacks before you can pull it off, though).

• complete singly linked list menu program (SLLMENU)
• complete doubly linked list insert functionality (09/19/2013)
• complete doubly linked list append functionality (09/20/2013)
• work on/complete doubly linked list remove functionality
• you will be implementing a separate doubly linked list menu-based program (DLLMENU). Be mindful of this as we progress.

• complete linked list append functionality (09/11/2013)
• complete linked list remove functionality (09/13/2013)
• add a menu onto the program so the user can operate the linked list (in progress)
  • menu should have: build list, view list, clear list, insert, append, remove, sort (least to greatest), and quit
  • move all linked list functionality to separate functions
• start contemplating linked lists with respect to your card game project

• Have the data types/size program finished (09/06/2013)
• look through C/C++ review program(s), and make sure everything makes sense
• look through the linked list code, and see if everything makes sense
• complete linked list insertion functionality (09/06/2013)

• Edit/customize the Title and Introduction sections of your Opus]] by start of class Friday, September 6th
• Subscribe a frequently checked (or pushed) e-mail address to the class mailing list
• When you come to class, remember to open a Lab46 terminal, which will be used for attendance/participation purposes.
• Make sure you can access the DATA course homepage from home (you may want to bookmark it).
• Make sure you can log into Lab46 from home with your username/password (using PuTTY if on Windows, or some other SSH client).
• Get on the class chat, and familiarize yourself with basic screen usage (attaching/detaching).
• Finish data type size example for all int variations.
• Play with data type size example, experiment with it a little.
• Clone and start using your personal Lab46 Mercurial Repository