#8 March 18

Welcome to the spring break edition of the 371p blog. I'm not entirely sure if we're even supposed to be writing one for this week, but hey I like tradition!

The only thing to discuss for this week is the Grades project. I had the impression that this could be easily done in a few hours. I was MISTAKEN! This has honestly been the most irritating project so far. The good first: implementation was a breeze and designing it by avoiding getters and setters was interesting and challenging.

But the sheer tedium of the formatted output! I think most of the time spent on this project was calculating what the width of a multitude of items would be and then how many corresponding spaces would make it look nice! Look, I'm all for formatted output - but please don't ask me to write unit tests where I have to manually count out spaces and -'s to the point where I'm going bat-crazy!

And that brings me to the next grouse - unit tests are good, but this "written-in-stone" 3 unit tests per function idea is not practical. There are some functions (like the constructors and destructors in the previous project) which don't need more than 1 or 2 unit tests. I often have way more than 3 unit tests for functions which have a number of corner cases etc., but I have started writing more monolithic functions (far less cohesive than I would want them to be) simply to avoid writing 3 unit tests for simple helper functions like calculating the number of digits in an integer etc. This is obviously not desirable and I hope Prof. Downing leaves it to the students' discretion as to what to unit test and to what degree.

I did learn a lot about C++ formatting - I'd become too used to the C-style printf format specifiers. The article on getters and setters was interesting too, though labeling them as evil is probably extreme. Anyway, I leave you with a meme I never knew existed:

#7 Mar 11

Well this was a slow week in the OOP class. Most of this week was spent discussing the ins and outs of arrays in C++. How we can only use it as a pointer when passed as a functional argument, how you can dynamically initialize them with values, but cannot initialize them with the same syntactic sweetness as int i = j. The same thing goes for when you're trying to reassign an array tonanother array. Something as simple yet dumb as a = b where a and b are arrays can actually cause a memory leak if you have created a on the heap. So it all boils down to use vectors - they are a part of the standard template library, they provide the syntactic sugar which lets you handle them very nearly like built-in types and are also blazingly fast about it. But what personally tilts the balance in favor of vectors is the fact that they handle all memory management on their own under the covers, so the chances of having a memory leak are now very low as compared to when we were using arrays.

This also brings us to our first really Object Oriented project for the semester. We're basically given a bunch of scores for students in a course and are expected to compute the statistics on it. While honestly this doesn't really need an object oriented approach to solve it I can still see why making a Student object might be helpful - especially is this were to go on to become part of a more complex system. The getters and setters are evil ideology makes a lot of sense once you think about it, and also brings up the question - how do you come up with a good design. In my case, I'm keeping most of the statistical functionality with the Course class and only personal stuff like ID and individual scores with the Student. Of course, this means that student objects will have to pass over their vector of scores to the course object, but I could not see a way around this minimal message passing. This project also made me realize how much I like Python :)

#6 March 4

Another week and some more intricacies of C++ come to light - the many different uses of the const keyword. While I have covered const pointers before, it's still handy to brush up on how const can change the usage of a variable or a pointer depending on how you place it in the declaration.

So let's break things down:
When you declare something as const, quite intuitively, you're saying that it can't be changed. This obviously means that a const variable MUST be initialized during declaration.
So, for example:

const i = 2;

would initialize the constant in i to 2 and then you would not be able to modify it (i becomes read-only).

This becomes slightly more tricky once you start using pointers:

const int* p = &i;
int* const p = &i;

In the first case, we're declaring a pointer to a constant, i.e., the value being pointed to by p (in this case i) must be constant and cannot be changed, while p itself can. Thus I can reassign p, but something like ++*p would not be allowed.

In the second case, we're declaring a constant pointer. This means once initialized to some address, we will not be able to modify p. This is particularly useful if you think of pointers being returned to indicate the start of an allocated memory location - we want to ensure that we keep this address constant.

There are other variants to this, including mixing it up with references, but once these 2 have been clearly distinguished, the rest fall into place.

#5 Feb 26

So begins the 2nd part of the course (I've logically divided it into 3 parts based on the Tests). First piece of advice - don't miss a single class! Due to personal reasons, I missed the class on Monday - when the 3rd project was being described - it's basically to implement the functionality of a heap. I felt lost when I came to class the other day - partly because there's no specs listed on the project page and also because I didn't realize how dependent I was to little things mentioned in class which help during quizzes and the project implementation. But I think I've caught up and now the project is going along full-steam ahead! Pair programming is going well - and I think I'm lucky to have found a partner who's as obsessive about correct indentation, spacing and brace-styles as I am!

So I don't have much material to talk about, since the class I did attend was mostly spent in re-introducing the different versions of the sum function for different iterators. Readings have finally started - and the quiz brought up the point of IS-A (inheritance) vs HAS-A (containment). For now, it's back to the project - we're knee-deep in pointer territory and you never know when a stray pointer could attack (the dereferenced ones are particularly vicious)!

#4 Feb 19

The week of the test...<Hitchcock scream + thunder and lightning>. Well, not so much - it was a pretty simple test if you've been following the material in class - and the best part was that most of it was a multiple-choice format which meant that we got the results in a day. I've always found the aftermath of a test to be more stressful than the test or its preparation, so I was quite happy.

This week we mostly covered different data structures, container classes and the cost of performing operations on those structures. But before I talk about that, there was one point made about using references instead of pointers which I really liked:
A reference always needs an l-value, so if you have a function that takes an argument by reference, mistakenly doing something like f(0) will cause a compiler error, but if you were taking the argument by pointer, then it would compile - but now you're dealing with that dark evil which has haunted programmers for centuries - the NULL pointer!

Back to data structures - the summary of all that was taught can be found in Prof. Downing's schedule here. Some interesting things in the discussion -

• A Deque is a variation of ArrayList except that instead of being front-loaded, it is center-loaded. This means that the cost of insertion and removal becomes an amortized constant - way better than the O(n) it was for insertion into an ArrayList. 
• Also, stacks and queues are backed up by sequential structures, but queues cannot be backed by vector since vector does not offer a push_front / pop_front functionality. (It's O(n) for front-access, but ~O(1) for back-access)
• Similarly, priority_queues cannot be backed by lists since they need to implement heaps which need indexing capability. Also, it can't be modified in place since it doesn't return an l-value.

Also, this week we turned in project 2  - the Australian voting problem. The problem itself was quite easy - the unit tests took a very long time, since the problem input was quite cumbersome. Also, we did it as a pair programming exercise. The experience was a mixed bag - it's always better to have another pair of eyes on the code you do, but managing time to have compatible schedules so that we could program together was more of a challenge than the problem itself. This led to us tackling the problem quite late, which is something I dislike since I prefer finishing off assignments as soon as I possibly can.
I'm looking forward to see how the other projects go. In the meantime, do not be fooled into extending the XP philosophy into your shopping patterns (from xkcd.com):

Btw, did you realize that a third of the course is already complete!

#3 Feb 12

This week was mostly a continuation of the discussion of exceptions. Some of the things that I found interesting:

• C++ can throw any type whatsoever, it doesn't have to be an exception (soon you might see an int hurtling over your head!)
• If you are doing exception handling in C++, you should always throw by value and catch by reference. Catching it by value leads to 2 copies (ugly) and catching it by pointer means you have to throw a pointer and that can lead to all sorts of memory management hell.
• Stack allocation is faster than heap allocation, so avoid using the new operator if you can.
• Wondering what the differences between references and pointers are? Well one is that you can always declare a pointer variable uninitialized and it's OK to reassign them to different variables. References NEED to be initialized to some variable, and like swans - they mate for life.
• Finally in Java, (I know this but tend to ignore it while programming) use StringBuilder when repeatedly concatenating Strings, since doing something like str1 += str2 causes a new String to be built and assigned to str1 while its older value is garbage collected (they're immutable, remember)

We also started on the UVa Australian Voting problem. The logic seems pretty straightforward, once you're past the reading/ writing issues. More on that next week.

#2 Feb 5

This week was submission week - and while Collatz V1 went as smoothly as a warm knife through butter, V2 nearly drove me insane with the obstinate "wrong answer" posted after 2 excruciating seconds of running the code. And I wasn't alone! This led tons of acceptance testing and then to a hailstorm of comments and discussions on Piazza - and finally it turned out that Sphere wasn't, in fact, expecting the right answer, rather one that had been masked to 32-bits even though the calculations clearly led to numbers beyond that range. Who would have known!! Anyway, Project 1 is done and dusted...and it's time to move on to Project 2, and with it, pair programming! More on that next week!

As far as class material goes, we've mostly been covering assertions and exceptions and also the l-value, r-value concepts related to operators. So far so good....more to come!