======Things To Do with DATA======

Things you should do before too much time passes:

======EoCE errata======

=====20131210=====

  * 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:

<code c++>
int Stack :: getListSize()
{
    return (this -> getQuantity());
}
</code>

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

<code c++>
int Stack :: getListSize()
{
    return (this -> data -> getQuantity());
}
</code>

It has been fixed in the provided code.
=====20131209=====

  * 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:

<code c++>
#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.
</code>

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=====

  * 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):

<code c++>
tmp -> setNext(tmp -> getNext());
</code>

and replace it with:

<code c++>
tmp = tmp -> getNext();
</code>
=====20131125=====

  * 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:

<code c++>
        Node * getStart();
        Node * getEnd();
</code>

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======
  * 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.

=====Week 7=====
  * 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.

=====Week 6=====
  * [[fall2013/common/data/llkatopictures|Knowledge Assessment]] (Part 1)! Be sure you know your linked lists!
  * [[fall2013/common/data/llkatocode|Knowledge Assessment]] (Part 2)! Be sure you know your linked lists!
=====Week 5=====
  * 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 [[fall2013/common/data/sllmenu|Singly Linked List Menu (SLLMENU)]].
  * I also put together a project page for the [[fall2013/common/data/dllmenu|Doubly Linked List Menu (DLLMENU)]].
  * The day is getting closer; closer to getting your [[fall2013/common/data/cardgame|FreeCell-based Card Game Project]] completed (still need libraries and stacks before you can pull it off, though).

=====Week 4=====
  * 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.

=====Week 3=====
  * 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

=====Week 2=====

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

=====Week 1=====

  * 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 [[http://lab46.corning-cc.edu/mailman/listinfo/data|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 [[http://lab46.corning-cc.edu/haas/fall2013/data|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 [[fall2013/common/repo|Lab46 Mercurial Repository]]