Final Post :(

So, I guess is the end of the road for me and Object-Oriented Programming, well, at least the class at UT Austin. Honestly though, I cannot stress enough how much I have learned in this class. Dr. Downing is by all means an asset to this University in teaching students about the world of C++ and the subtleties of different Object Oriented programming languages.

I recently took my last exam in the class last Friday, and while I did not do too well, I understand each and every error I made. The truth is that I did not get a whole lot of sleep the night before because I was working on an Operating Systems project that was due at 8 am. The project, however, was in C++, and the subjects we learned about in Object-Oriented Programming proved vital to complete the project. I have no idea how anyone else who did not already know C++ came up with even a half-decent design when they were too worried about just getting their code to compile.

My only wish for this class is that I would have done better on the tests. It really irks me that I made the mistakes I made during test time. The thing is, I did stellar on all the projects, barely missing any points. I do very well in the application of the things I've learned in a development environment, but when it comes time to take the test I get a little anxious and answer questions too quickly.

It is because of this class that I have taken some leaps into C++ and that C++ is now my favorite programming language. It is light years faster than Java, and the amount of power it offers is incredible.

A++. Great Communication. Would take again!!!!

Making Wrong Code Look Wrong

"Making Wrong Code Look Wrong" is an article by Joel Spolsky that articulates the necessity and benefits of adhering to coding standards that make incorrect code literally stand out to your eyes. For those that do not know, Joel spolsky is the co-founder of Fog Creek Software and Stack Overflow and has written countless articles on coding semantics and best practices that can be found on his website.

When we first begin programming in a new language, we often times have trouble seeing incorrect code. I know when I was first learning Perl I had an extremely difficult time spotting bugs by just looking at my code. I did not know clean from unclean and did not understand good coding conventions specific to the language. Joel says that ultimately you will understand a superficial level of cleanliness and will begin to see incorrect code to the point that you will want to reach out and fix the code.

Often times when I am coding, especially when I am building on code somebody else wrote, I typically will change things as I go along to conform to the coding standard that has been established at the time the project was issued. I can definitely sympathize with Joel when he talks about the temptations of attacking incorrect looking code. To the employer or manager it can seem like it is wasting a ton of time modifying code to conform to some kind of static curly brace convention, but in the end it is the uniformity that will train the eye to spot the bad eggs in the code. It is always best to establish a coding convention at the beginning of a project, and not after thousands of lines of awkwardly connected code has been put in place.

Joel moves on to establish a general rule for making wrong code look wrong. If you can see a variable on the page, you should be able to tell everything you need to know about it right then and there without looking at some other function, a macro, a global in a header file, or scouring through some class hierarchy to find what you are looking for. In the land of C++, this can be especially difficult. If we are using simple variable names like i and j, just looking at the following statement can be utterly unhelpful:

    i = j * 5;


In C, we know that j is being multiplied by five and the results are being stored in i. Easy. But in C++, an object-oriented language, we know nothing about what i and j are. We don't even know what this is doing! If i and j are built-in types, then fine, it is probably doing a multiplication of some sort. But, fact of the matter is that i and j could be user-defined types that has operator* overloaded, and we will have to go searching through the class hierarchy of the type to find out what is going on. And really, we can't really know exactly what is going on if some kind of polymorphism is involved because we need to the type i and j are now and not when they were simply declared. Don't get me wrong, these are the kinds of features that make C++ work beautifully, but with great power comes great responsibility, and I don't want to be the one searching through your code because you thought you were being clever about something. 


This brings me to another point that Joel talks about, and one that I find hits particularly close to home. I used to think that writing clever code was the bee's knees. Everyone would succumb to the power of my witty loops and if statements and automatically think it was the coolest thing they had ever seen. This is BAD. If there are no performance benefits for cleverness over being simply writing the simplest and easiest-to-understand line of code, then why not save yourself the headache later when you forgot what was going on? Let's take a super simple line of code like the following:


    if (status == 1)
    status--;


First of all, for the last time will you please put the damn decrement operator before the variable? Anyways, if I see this sequence of code, my first thought is that status must be some sort of numeric value, but I can't know for sure. The same questions arise: Is status an integer or other numeric value? Oh clever you, is it a boolean? Or... Could it be a user-defined type in which both operator==, and operator-- are overloaded? The truth is I simply have no idea without looking somewhere else, and Joel gives a nice solution to making this easier to understand: Hungarian Notation. 


Hungarian Notation is a coding notation invented by Microsoft programmer Charles Simonyi. In Simonyi's version of Hungarian Notation, every variable is prefixed with a lowercase tag which indicates the kind of thing the variable contains. The problem is that when Simonyi wrote his paper on Hungarian Notation, he made it very academically dense and made a brutal mistake that led to many misconceptions by following programmers later on. He used the word "type" instead of "kind" when referring to the first lowercase letters. While his paper clearly shows that he did not mean the defined type of the variable, many people, including all of Microsoft took this as literal, and soon all of Microsoft's code had the type of the variable prepended to it. This is nice and all, but isn't it better to not only give information about what a variable is, but also what it's doing? By prepending the kind of variable we can not only get a glimpse into what the variable is, but also what in the hell it is doing. Using the intended notation it is far easier to see errors in lines of code that would otherwise be invisible. Let's say we have an int prepended with the letter 'ts', representing "thread status", and another with the letters 'pc' representing process status. If this convention was understood, it would be apparent that the following line makes absolutely no sense:

    ts_status = pc_status; 


By seeing that they are differing status "kinds", we can easily see that the thread status is probably not supposed to have the same value as the process variables status. I wasn't there when they created the imaginary "kind" convention, but the idea is that it was understood by everyone involved in the creation of the code, and that the preceding line of code is incorrect even to the naked eye.

One thing I do find intriguing in Joe's article is his incessant hatred and disapproval of exceptions. I can see where he is coming from in regards to the article, and that is that with every function and method call, the programmer has close to zero idea if that function can even complete unless he or she knows whether or not the function or method throws an exception. This often times means searching through inherited classes and other files to see what is really going on, which is exactly the opposite of the standard Joel is trying to get across. Raymond Chen says the following:

"It is extraordinarily difficult to see the difference between bad exception-based code and not-bad exception-based code... exceptions are too hard and I'm not smart enough to handle them."

 Basically, it is almost impossible to tell whether or not exception-based code is bad or not to the naked eye. If you're going to code with exceptions, you better have some pretty serious standards set in place or else risk your end product breaking at extremely inopportune times (and give all of the other programmers involved a serious headache). 

The key is to write simple tools that humans can see and understand, not complex ones with all kinds of crazy hidden features and abstractions that assume all programmers are perfect.

Multimaps

So recently on an operating systems project I had to come up with a data structure that mapped a set of keys to an arbitrary number of values. To be specific, each key is a username, and each value is a list of sessions that is associated with the user.

My first instinct was to simply use a map< string, list<size_t> >. It is easy to understand and it offers easy access to the values with map's overloaded indexing operator and an iterator over the list. This works perfectly fine, but it did not allow me to do something I had never done before, so I decided to be a little wild and use something called a multimap. If one looks at the stl reference for multimap, he or she can see the definition is rather simple:

Multimaps are a kind of associative container that stores elements formed by the combination of a key value and a mapped value, much like map containers, but allowing different elements to have the same key value.


Perfect! This is exactly what I needed. It was all good and fun until I began to see the horrible wretched syntax that is involved in using these forsaken data structures. While the initialization looks normal:

multimap< string, size_t> sessions;

In my opinion not a single method in the API is intuitive. You want to insert an element? That goes something like this:

sessions.insert(pair<string, size_t>(username, session_number));

Everything has to be inserted as pairs, which makes inserts very non intuitive. If we had done things the map<string, list<size_t> > way, it would have gone something like this:

sessions[username].push_back(session_number);

So, moving on, I needed a function that would check if a username had a specific live session associated with it. With a multimap we get a hideous function that goes like the following:


/**
 * Utility function to check if a username has a specific live session
 */
bool find_session(const string& username, size_t session) {
        //find returns an iterator
        multimap<string, size_t>::iterator it = sessions.find(username);

        //use equal_range to get the range of elements with the same key
        pair<multimap<string,size_t>::iterator,multimap<string,size_t>::iterator> ret;
        ret = sessions.equal_range(username);

        //ret.first is the lower bound, ret.second is the upper bound of the range
        for (it = ret.first; it != ret.second; ++it) {
                if (it->second == session) return true;
        }
        return false;
}


This particular pair of lines looks horrible:


 pair<multimap<string,size_t>::iterator,multimap<string,size_t>::iterator> ret;
        ret = sessions.equal_range(username);

This is very non-intuitive, and that declaration is extremely messy in my opinion, albeit very explicit about what it is doing.

Now, the bright side is that with C++11, this code can be made much prettier using the auto keyword that will do some magic to clean this up. Since one of my fellow brogrammers is blogging about this, I will not still his thunder, but merely request that he rewrite the function below in the comments using the keyword. :)

A New Way to Test

In the previous project for Object-Oriented Programming, or "Brogramming", (since we always program with partners :) ) I was trying to conjure up new ways to get access to my private variables from cppunit tests.

The ugliest way is to use getters and setters to play with the variables you want to check and modify. Using getters and setters is typically frowned upon though, and there are much better ways to test your code, especially if you are only creating the getter and setter methods for testing purposes.

One of the ways that was conversed about in class was to make the test cppunit structs friends of the classes you want access to. This gives the cppunit tests access to all of the variables, and we can do our testing without the hassle of dealing with getters and setters. The problem with this is that we literally have to declare the test class or struct a friend in each class or struct we want access to, and I would argue that putting these friends in your classes can needlessly clutter source code, even it is only a few added lines.

I then got the wonderful idea of using macros to play with the private, public, and protected declarations within the classes, isolating the test file access from the body of the source code. The first option with this is to do something like the following:

//not the test file
#ifdef test_mode
    #define private public
#endif

//testfile
#define test_mode

This could be considered by some to be a little on the dangerous side, so at this point I introduce a tradeoff. In one hand, we could simply give anyone who defined "test_mode" access to all of the private variables in the class we are trying to test. In the other we could do something a little more complex like the following:

//not the test file
#ifdef test_mode
    #define private protected
#endif

//testfile
#define test_mode

So instead of simply making all of the private variables public, we make them protected. Why? Well, in this case any class which is a child of all the classes in the source file being tested will have access to all of the previously private variables. The idea is that now we can simply declare the test class a child of the class(es) we want to test and test away!

Elegant Copy Constructors and Assignment Operators

So recently I discussed the importance of adhering to the Orthodox Canonical Class Form, and in this previous week in class I learned of a very elegant way to complete two of these: the copy constructor and the assignment operator. As long as you are careful, these two methods can often be very simple to write and do not typically require a large amount of thought. Most problems arise when there are pointer variables as fields in a class. Using the default assignment operator will simply copy the address of the pointer over which results in two variables pointing to the same address. Honestly, I am having trouble recalling how I used to do this because this new method I have learned of completing these two tasks as nullified all of my old practices.

So let's say we have this class, my_object, and in this class we have only an int and an int* as private data fields for the class, like so: (Yes, it is stupid, but I am simply trying to show a point).

class my_object {
    private:
        int x;
        int* y;
};

Now, we do not want the default copy constructor or assignment operator, because they will both result in some nasty pointer bugs. We want each instance of my_object to have its own value of y, and more importantly a unique address for y! So, we will continue on to create the copy constructor using C++'s interesting syntax for initializing variables in the method declaration:

my_object::my_object(const my_object& that) : x(that.x), y(new int) {

    *y = that->y;

}

Notice that I accepted that as a reference, and that I simply initialized this->x to that.x, and that I created a new int on the heap and set its value to the value of that's y in the method body. How can we write an assignment operator that takes advantage of the copy constructor we just created? I would argue that this can be done precisely how Professor Downing enlightened me in class. First I will show it here and see if you can figure it out:

my_object::my_object& operator = (my_object that) {

    std::swap(x, that.x);

    std::swap(y, that.y);

    return *this;

}

In the words of Dr. Downing, "Beautiful!". Really, I truly believe this is a beautiful solution. We created the copy constructor that took care of the pointer copy issue, and simply passed the my_object by value in the assignment operator such that a correct copy is created, and we can swap the variables out of the object to get the proper assignment.

Interview With ARM

I had an interview with ARM last week, and I truly believe that if it were not for Dr. Downing's wonderful Object-Oriented Programming class, I would not have felt nearly as confident going into and during the interview. While Arm really is not the type of company that requires an army of computer scientists, it is interesting to see how they are currently looking to see how computer scientists will adapt to different environments and how they can apply an abstract view to different problems.

One of the recurring themes of the interview was the subject of a GUI they were interested in designing. Even though I do not have much experience with GUI's, I am still confident that I would be able to create one without a tremendous amount of difficulty. After all, it is just object manipulation and message passing. Regardless of whether an object is representing a frame on the monitor or some abstract data structure, it is still just an object that can be asked to do things and/or produce some result given a message or what state the object is in.

Pertaining to experiences in this particular OOP class, the interviewers were also interested in experience with version control software, issue trackers, and most importantly, proper documentation. The engineers loved to see that I have experience with git and svn, and loved the fact that I keep almost all homework under version control even more. Two of the code samples I sent were in fact projects from OOP, and they thoroughly enjoyed looking at code in which each function and method was documented well and easy to read.

While I do not have the job yet, I am anxious to see how the job will play out if I am hired. As of right now it seems I would be working mostly with engineers, and I am very curious of how my abstract brain can apply itself to the lower levels of the computer world.

Avoiding Setters and Getters

For the novice programmer who is just beginning to delve in the world of object-oriented programming, setters and getters are typically the goto method of manipulating data fields of objects. Sometimes it is difficult to program without using setters and getters, specifically getters. It is often necessary to ask an object what kind of state it is in, or the value of some data field it holds. This is nice and all for testing and quick/dirty class creation, but it fails to shield the programmer and other objects from its implementation. Ideally all classes should hide all of the dirty details of the class and instead perform the computation that another class would use the value for in the first place.

In the current project in OOP, this has been a real chore, but this one of those projects that can be a disaster if designed poorly or a lot of fun if designed with good object-oriented design practices in mind. The project basically consists of a grid that holds creatures of different, or equivalent species. These species can turn, move around, and infect other creatures such that they are now the same species. In this picture, it is easy to see that there should be a grid, creature, and species class, in which the creature holds some form of a species.

The question is: How does the grid communicate with the different creatures on the board without simply asking for different data fields? How will the grid know which direction they are facing? How the instructions of the different creatures be passed around? The easy approach would be to have the grid simply ask for different data fields of the creatures and do all of the computation itself, but this is ugly and can lend itself to debugging disasters. It is much cleaner to give the creature some information based on what is in front of it and have it do some computations based on its own data to figure out what to do next , and then relay that information to the grid.

It is just lately that I have been forced to program without the use of getters and setters. While they do have their purposes in some cases, I am beginning to see how objects can communicate in a much more elegant and purposeful fashion if they are avoided.

Redemption

So, we had our second test in OOP last week, and I would like to take the time to give a little feedback about it via Dr. Downing's request. I feel as though I did much better on that test than the first, coming out of the test feeling much more confident than I did with the first. For this particular test, I studied and focused far more on understanding the slides and quizzes rather than simply trying to memorize them. Really sitting down and trying to understand the difference between the different iterators and what was really happening in the examples proved to be very useful.

In some of the previous projects me and various partners ventured out a bit and tried our hands at declaring objects on the heap, even going so far as to create custom linked lists and understand how to manage them correctly. I think doing that and understanding what was going on during the construction and destruction of objects did a lot in helping to explain the two part process that happens when deallocating objects. That is, the objects are deleted and the memory the objects possessed is then freed.

I do think the test may have been a little one-sided on certain subjects. Many people said that if one did not understand one question, he or she would very likely not understand the surrounding three or four questions. I find this somewhat true, but I also believe that one could logically infer the answer from the other questions. Or rather, one could infer the logic to answer a question from analyzing similar questions.

One question I like to ask myself when asked questions dealing with language semantics pertains to asking how the language would act in certain situations if I wrote it. After all, programming languages are designed to be as eloquent and logical as possible, and in my opinion should have predictable functionality to the programmer. Then again, C++ can be very, very complicated, but I will take any mindset I can get that gives me more confidence in a test.

The Beauty of Lists

So, if you take a look at my last post, you can see that I have taken a liking to the use of vectors over arrays in C++. While the current project in OOP naturally calls for a "has-many" relationship between two classes, I have found that there are other, possibly better options to use than vectors.

Lists, under the right circumstance, can prove to be a good option when random access is not required. This last week in another project from an operating systems course, a situation called for use of a linked list. It required a list of objects that was sorted under some characteristic defined in the class, and it required that addition of elements be as cheap as possible. Well, it turns out the C++ STL has a wonderfully built list already that I have only begun to scratch the surface of. In order to maintain the list in sorted order, it is as simple as overloading the "<" operator, pushing an object to the front of the list and then simply calling the sort function from list. i.e. someList.push_front(someObject) and then doing someList.sort(). While sorting vectors typically involves copying, for lists all that is required is rearrangement. Or in the words of the C++ reference:


The entire operation does not involve the construction, destruction or copy of any element object. They are moved within the container.


Sorting a vector, on the other hand, typically calls for the use of algorithm's sort unless a custom sort is created, but I really do not see why you would when creating comparison functions and using built-in sorts are so easy.

Some might argue that inserting into a list is actually more expensive than inserting into a vector. In some cases I could see this, because for small types it is extremely simple for the L2 cache to do its work on the entire vector (say if we are pushing to the front of the vector). For larger objects, as containers grow in size, this could prove to be a problem as the amount of copy calls grows. 


I would love to hear some points on the efficiencies of vectors vs. lists in the comments!

The Beauty of Vectors

After months of only using arrays in C++, I have recently started using vectors as my go-to basic data structure. While arrays are great for lower level code and tasks that require the highest level of efficiency, in most cases vectors will prove to handle things in a much simpler and more elegant way. I personally like that vectors provide the user with a way to retrieve the size of the vector. It is no longer needed to keep track of the size of an array with a separate variable, which can really make vectors easier to work with.

Often times when using simple arrays it can be a nuisance to deal with managing the objects they hold. Vectors also work magically with memory. When vectors go out of scope, it calls the destructor on the elements it holds. I would argue that using a smarter container like vector instead of an array decreases development time because it helps reduce programming errors.

One of the interesting caveats involved with using vectors is the way iterating is handled. At first glance, it can be easy to assume that a simple for loop from int i = 0 to some_vector.size() would work just fine.

for (int i = 0; i < someVector.size(); ++i)
    cout << someVector[i] << " ";

Well, it does, but the field that holds the size in vector is unsigned, so a type warning occurs at compile time, and that means there is probably a better way to do it. The first, simple fix, is to simply change the type of 'i' in the loop to an unsigned type so that the comparison i < someVector.size() will not result in a warning. Unsigned int will do, but it turns out vector actually uses the size_t type for this purpose, and that ends up being a far more correct solution than simply using an unsigned specified type.

for (size_t i = 0; i < someVector.size(); ++i)
    cout << someVector[i] << " ";

We can still do better by using iterators instead of using the standard for loop. Vectors have both a begin() method and an end() method that both return iterators. (Obviously begin returns an iterator to the beginning of the vector and end returns an iterator to the end). Hell, we could even use rbegin and rend which return reverse iterators. Here is the simplest way to use them in one for loop:

for (vector<T>::iterator it = someVector.begin(); it != someVector.end(); ++i)
    cout << *it << " ";

Notice that in this case we had to dereference the iterator object since it is simply pointing to the consecutive elements in someVector.

Anyways, vectors are proving themselves to be a very, very cool alternative to arrays. When using them just be careful that you initialize them properly if the initial size is known. Check them out! http://www.cplusplus.com/reference/stl/vector/

The Orthodox Canonical Class Form

Every "good" programmer has heard it and knows it: the canonical class form, the "must-haves", the four methods every class needs to possess a certain degree of thoroughness in acting out its purpose. In case you have forgotten, I will go ahead and relist them again here:

1. Default Constructor
2. Copy Constructor
3. Assignment Operator
4. Destructor

While this explanation will be stated according to Timothy Budd's Introduction to Object-Oriented Programming book, I believe he does a great job of outlining each of these methods and iterating their purpose to the reader. The default constructor is used to initialize objects and data members when no other value is readily available. There is of course in most cases a default constructor, but relying on the default constructor is typically not a smart choice. The copy instructor is used in the implementation of call-by-value parameters. The assignment operator is rhetorical, and the destructor is invoked when an object is deleted. The copy constructor, to me, seems to always be the least necessary. How often do I actually need to copy an object when I already have access to the original? I typically pass objects as pointers, but I can see how working with others and failing to write a copy constructor could cause somebody to shoot themselves in the foot when passing values by value.
I am sure most readers have these four functions hardwired into their brains, but it is always good to reiterate! I personally fail to always take care of these things, and my goal is that this post will remind me to think through what I am doing and about the issues that can arise when the canonical class form is discarded. I would enjoy hearing some other purposes for the canonical class methods in the comments below!

CGDB: My New Favorite Debugger

I have just recently begun delving in the use of debuggers. For some odd reason my previous professors never encouraged their use or mentioned their existence. As I have started to move into more projects involving C and, in Object-Oriented Programming, C++, the C/C++ debuggers available have proved to be a godsend in finding and correcting bugs. First I began with standard gdb, which is nice, but I really yearned for something that integrated a little better with the source code and had more readability. Then I found out about the -tui flag for gdb. This opens a nice window for the source code and creates a nice gui in the terminal for gdb. Stepping into certain functions pulls up the source for that function regardless of what file it is in, and setting breakpoints does not require me to have the file open in another pane or tab in order to figure out the correct line number. After that, I thought gdb -tui was all I would ever need, and I would never go back to using standard gdb. Many people would argue that ddd is much better, but given that it uses X windows, I would much rather use a terminal debugger and keep my hands off the mouse. The graphical front end is nice, but it involves too much clicking, and the font ddd uses is horrendous.

Then I found something amazing: cgdb, the curses debugger. Given that I am a die-hard vi user, this nifty debugger is one of the coolest tools I have found for debugging C and C++ code. The front page of the cgdb website, which I have linked above, shows a few of the features:

Features

• Syntax-highlighted source window
• Visual breakpoint setting
• Keyboard shortcuts for common functions
• Searching source window (using regexp)
• Scrollable gdb history of entire session
• Tab completion
• Key mappings (macros)

It follows the same general escape and insert modes that vi uses, has syntax-highlighting, which neither ddd or gdb -tui have, and allows for regex searching through the source code. With cgdb I can still work in the terminal and continue to maintain the vi-oriented mindset I have become so accustomed to. I doubt I will ever come across another debugger as clean and readable as cgdb. It has earned its spot in my toolset, and although it is just an ncurses frontend to gdb, it is very well thought out and made a great tool even better. 

Never forget the stupid solution

If there is anything the last project taught me, it is to not declare variables on the heap if it is not required (see my previous blog post), and to always make a stupid solution first. A stupid solution is simply the quickest and least complicated way to solve a problem. Before going to attack a problem with guns blazing, it is always better to get to know the problem a little first. A lot of times programming I feel like the problem at hand is always some kind of opponent, and taking necessary preparation and precautionary measures is imperative if beating the opponent is something to be desired.

In my particular case, the failure to create a stupid solution resulted in a lot of pointless work between me and my partner. Now that the project is done, I am finding more and more that had we chose to create the simple solution first, it would have decreased the time spent on the project by > 10 hrs, possibly more. We went into a fight with guns blazing, throwing classes, linked lists, and structs at a problem that required nothing more than a few arrays. As I stated in my previous post, we still learned quite a bit about constructors, destructors, and the creation of linked lists in c++.

Sure, it is always nice to try and be fancy, but being fancy does not always get you the grade, or get you the job, or let you keep your job. Dr. Downing stresses on every project the importance of making the stupid solution first. Now that I have seen firsthand the consequences of failing to do so, the creation of a simple solution is now on my checklist for solving programming and other problem solving problems. After the creation of the simple solution, it was only a few tweaks away from the final product (albeit a few very thought-provoking tweaks) and ended up being a much shorter and understood solution than what we had before.

I encourage everyone to do the same. It might seem at first to only waste time in getting to the final solution to a problem, but like I said, the battle can be better fought if you get to know the opponent a little better first.

Australian Voting

If a professor tells you that declaring variables on the heap is not necessary for a project, simply do not do it. This is the lesson I am currently learning in regards to project 2, Australian Voting. The problem itself is very interesting, demonstrating a voting scheme I have never seen before. Put simply, all voters rank the candidates from their favorite to least favorite, and no candidate receives a majority vote in a round of voting, the losing votes are moved to their next ranked candidate. Seems simple enough, right? It is, except a doable problem can easily become a huge chore when terms like "new", "delete", and "pointer to a pointer" start being thrown around. While this is taking me and my partner a little longer than it should, I know that in the long run it will pay off, because we are learning things that will help not only later in this class, but later on in the industry as well.
  To be specific, we first started off using a linked list to store ballots (we will not go into details until after the project is due), and after that turned into a nightmare, we used vectors and arrays, and lastly we are using just arrays. The linked list poised the most problems, where we were deleting elements in the list twice unknowingly. The same thing happened with vectors, and it was not until later that the bad memory management was just the beginning of our problems. Lesson learned: Do not blow a project out of scope. Do not make it more than it has to be. If there are no requirements restricting use of the heap, by all means use the stack, and think about all the hassle you are saving yourself.

Pair Programming

As a student in computer science, I am often given the choice to either work on a project alone or with a partner. While it seems like a trivial choice to me to go ahead and double the amount of brain power available on a project, there are studies that show benefits of both. There were two papers pertaining to the benefits of pair programming that were required readings for class. The first, titled All I Really Need to Know about Pair Programming I Learned in Kindergarten, essentially iterated through a list of adolescent morals creatively applied to the practice of effective pair programming. I find the list so interesting I will just go ahead and post it here:

Share everything. 

Play fair.

Don’t hit people.

Put things back where you found them.

Clean up your own mess.

Don’t take things that aren’t yours.

Say you’re sorry when you hurt somebody.

Wash your hands before you eat.

Flush.

Warm cookies and cold milk are good for you.

Live a balanced life – learn some and think some and draw and paint and sing and

dance and play and work every day some.

Take a nap every afternoon.

When you go out into the world, watch out for traffic, hold hands and stick together.

Be aware of wonder.

While some seem to be a little forced in terms of relating them to good pair programming practice, most gave an interesting take on how to effectively program with a partner. "Wash your hands before you eat" refers to the act of washing out any form of skepticism in regards to pair programming. Each partner needs to really "buy in" to the idea in order for it to work. "Flushing" keeps people from getting too attached to code that does not work. Sometimes a fresh slate is needed in order to go on with the project. Of course, there are many other ideas here that emphasize the act of sharing the work with the partner and keeping each other from stressing out. Taking breaks is important along with not taking things too seriously. 

The second paper, which was a study on First Year Students' Impressions of Pair Programming in CS1, demonstrated not only many of the benefits of pair programming, but also those of working alone.  Often times difficult problems require intense thought that can only be available when working alone. Then again, it makes sense for two people to come up with their own ideas for difficult problems and then later collaborate to see which algorithm or approach yields the best solution. 

In my years in computer science I have found a few stubborn people that believe they are indeed smarter and more efficient than the other partner when paired up for pair programming assignments. It is this kind of attitude that employers do not want to see, and even if you are smarter than your partner, it never hurts to have another resource consistently available at your disposal. Two brains are almost always better than one.

Frustration With Memory Management

Well, this might be slightly unrelated to "object-oriented programming", but the issue still applies to C++ and is applicable to the nature of this blog. I have just finished my first real project in C, and while not it was not in Professor Downing's class, it taught me a good deal about memory management. The project involved creating a list of sorted point "objects" (which were really structs), and to my eyes it seemed the idea lent itself well to the creation of a linked list data type. The sorted point structure would hold a pointer to the head of the list and the number of elements in the list. It seemed simple enough, but creating linked lists in a safe language like Java and trying to apply the same concepts to C do not completely work. C (and C++) will not simply throw away the nodes in the list when they are removed. Instead, they will sit there until the code tells them that they are free and available for use again. The main problem I had was that the sorted point structure was being allocated twice in the heap: once in the tester file and once in the sorted point init function. While it took much longer than it should have to find the bug, I gained some knowledge on some tools that we have used in 371p and some that I am positive I will be using. For the former I am referring to Valgrind, the utility which essentially yelled at all of my lost blocks of memory. While sometimes the information it gives can be a little ambiguous, it is definitely correct, and it can make you feel like an idiot even though your code might be producing the correct output. I will say that seeing the following three lines can be a huge sigh of relief when debugging code:


definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks

Speaking of debugging, I had a first-time experience with another tool today: GDB, the GNU Project Debugger. It is a very cool utility that allows you to trace through your code, step through functions, see the stack trace, set new values to variables, set breakpoints, show the values of variables at any time, and much more. I mainly used it with the -tui flag which pulls up a nice interface in the terminal that will show you where you are in stepping through the code. While debugging is never a fun task, it was interesting getting to use such a real debugger for the first time.

Memory Management is a beast that demands perfection from the person writing the code. There is no room for mistakes and no place for slackers.

First steps...

Hello everybody, my name is Cole Stewart and this is the first post of my blog that will be a "learning journal" of things taught in CS 371p, Object-Oriented Programming, with Professor Downing. As of this moment, I have had about a week and a half in the class, and I can already see that it is going to be an interesting, albeit intense, time absorbing the techniques, skills, and knowledge this class has to offer. The primary focus of this last week was a variant of the Collatz conjecture, which me and the other students have to solve using both Java and C++. The process is as follows:

Take any number n.

If n is even, divide the number by 2. (n/2)

If n is odd, multiply the number by 3 and add . (3n + 1)

The conjecture basically states that the process will always reach 1. While it has not been correctly proven that all positive integers reach one, my tests have shown that many in fact do, although it would be impossible to test every possible positive number. 

Our variation of the problem consisted of finding the max cycle length over a positive range, with cycle length being the number of iterations the process takes to reach one. In order to complete this problem we are being asked to use a tool called Sphere which is essentially an online judge that will compile code and run a set of tests on it to determine whether it passes requirements for a certain problem. It is very interesting to see how various optimizations in the code will either decrease running time, increase running time, and how my code fairs against other's. On top of using the Sphere Online Judge tool, we are being asked to use many other online tools, such as the git repository hosting available at Assembla and the issue tracker available from Google.  I have had previous experience with git, so that is not much of a problem, but using an issue tracker, and how to use one efficiently is new to me. It seems it is providing a very nice way to coordinate issues in a project, whether the issues be in code or things that need to be done. It is also important to note that Google also provides tools for project hosting like that at Assembla, but it forces the user to use a set of tools provided by Google, and to abide by a number of other limitations that make it unsuitable for our purposes. 

Mainly, for this project getting to see the difference in efficiency between the use of Java vs. C++ has been much of a shocker to me. My experience with C++ is minimal, and getting to observe the variations in running times and memory usage has been much of an eye-opening experience. For much of my Computer Science career here at the University of Texas at Austin I have been forced to mainly do projects in Java's handcuffs, and I am glad that I am finally getting the opportunity to not only get my hands dirty with C++, but to also learn how to write in C++ correctly and efficiently. I am already very much excited for what this class has to offer and am looking forward to a great semester and more great blog posts!