ECS 60 Programming Assignment #2, 50 Points (My Time 3 Hours!!!) Spring 2017
ECS 60 Programming Assignment #2, 50 Points (My Time 3 Hours!!!) Spring 2017
) Spring 2017
Due Wednesday, April 26th, 11:59pm.
Files to handin to cs60 p2 are: BTree.cpp, InternalNode.cpp, InernalNode.h, LeafNode.cpp, LeafNode.h, authors.csv.
Files: BTreeDriver.cpp, BTreeDriverDebug.cpp, BTree.cpp, BTree.h, BTreeNode.cpp, BTreeNode.h, InternalNode.cpp,
InernalNode.h, LeafNode.cpp, LeafNode.h, Makefile (uses BTreeDriverDebug.cpp to produce BTree), and Makefile2
(uses BTreeDriver.cpp to produce BTree2), QueueAr.cpp QueueAr.h, vector.h, vector.cpp, dsexceptions.h.
Your program will read a file that contains a series of integers that it will insert into a BTree, and then print to the
screen a breadth first traversal of the BTree. You will find all files, including my executables, in ~ssdavis/60/p2. Your
task will be to provide the implementation code for the BTree, InternalNode, and LeafNode classes. Since the insert
methods for the nodes will be quite long, you should add new methods so that no method is more than 30 lines long. We
will not grade on style, but the TAs and I will be of little help with poor quality code. You may only alter those files that
will be handed in.
The program will take three command line parameters: 1) filename; 2) M, the number of children that internal
nodes have; and 3) L, the number of integers each leaf node holds. The input file will not include more than 1000 integers.
Since only integers will be stored in the BTree class, I did not implement it as a template. When a node splits, the new
node created will always contain at least as many entries as the remaining old node, and will contain the larger values.
The output must match that shown in the sample.
There is one change in the data structure from the books; the internal nodes should keep track of the minimum
value for every child. You will find this easier than not having the minimum for the first child.
How did I write this code so fast? I used procedural abstraction. I thought about the tasks, their subtasks, and the
subtasks of those subtasks. (You should write them down.) If I could state a subtask, then I planned on writing a separate
function to do just that subtask. I found that the tasks of the InternalNode class matched that of the LeafNode class, so I
postponed as much work on the InternalNode class as long as possible so that I could learn from my LeafNode mistakes.
I worked top down with stubs for the subtasks, and got that iteration to compile without warnings! This avoids making
the same mistake repeatedlythe compiler is a very good teacher. When I could do even minimal testing, I did it. What
I learned from debugging kept me from duplicating those mistakes in later code, and reminded me of issues that I had
forgot about. Sometimes when I addressed a new issue in a method I discovered that I had to add a lot of code. If there is
a whole lot of new code, the issue deserved its own method with an appropriate name. It is a simple matter of cutting and
pasting, and keeps each method short, and understandable. By the time I was done my LeafNode class had nine methods,
and no method has more than 30 lines. Once the LeafNode class worked perfectly, I copied the LeafNode class methods
as InternalNode class methods, and did a search and replace from values to keys! Though there are child sibling and
parent issues for the InternalNode class, the basic LeafNode code provided a great starting point. In the end my
InernalNode class had 13 methods. In comparison to the first time I wrote this with long insert functions a few years ago,
the debugging was much faster this time because of the small methods
Here is a good progression of parameters for testing using BTreeDebugDriver.cpp. You should compare your
output to that of mine.
This is the most complex, time consuming program I ever assign. START EARLY!!
Here are a couple of other "tricks" that I DO use. I keep my functions alphabetized within each class, except that
the constructors and destructors are listed first. I write the name of the function, after its closing "}". Both of these make
searching for functions quicker. Besides the standard "}" comments of ECS 40, I provide comments whenever something
is the least bit tricky. For example, what is the value of pos after the for loop? Is it the position for insertion, one before,
or one after? Handy to know, a ten second comment when I write the for loop, and a pain to remember an hour later.
Sometimes I describe the state of the object when it enters a function. It is effortless to write these comments when I am
writing the code initially, and incredibly useful when debugging. Ten seconds now, can save minutes (or possibly hours
for you) later on! I try to avoid using "i" in loops when there is a better name, such as pos. I may write the loop with i,
and then do a quick search and replace with pos, or some other longer, more descriptive name.
I found I sometimes had to cast to the proper class type to deal with siblings, e.g.,
((LeafNode*) rightSibling)->. To avoid a ton of seg faults, test for NULL pointers before dealing with a parent or
sibling. You may use the buildbags.cpp program in the p2 directory to construct files if you wish.