Week 9 - Burnout Recovery (Oct 22 to Oct 28)

This week opened up with a nice hearty exam. The kind of exam that is designed to be so unlike any previous exam or homework ever given in the history of the class so there's absolutely nothing you can do to study except know the material inside and out and pray.

I can see the pro's to giving a test like that but overall it seems a bit unfair when you can look at your test grade and say: When I practiced with the test that was given last year, I aced it without studying, and then after studying for days, I failed the actual test? What? There's too much variability in what people will know after studying that some people get lucky and other people get screwed.

---

Luckily, OOP has reasonable, well-designed tests by comparison.

But after finishing up project 4 and recovering from the last couple of weeks of not getting enough sleep and being totally burned out, I look back on this test and it seems similarly inconsistent. Luckily when it's a project you're talking about, it's much easier to sort out the confusing issues over a long period of time but what I'm talking about is design.

I find it hard to believe that the same professor who teaches a software design class would also teach a class where good design is so readily ignored. I'm sure not a single student in this class who has ever worked with C/C++ would say that the way we're organizing the code in a reasonable way. We write all of our code in a single .h file! I mean, I understand that this makes it easier for the grader in a sense, but it makes it much more difficult for the students to deal with, and we're learning bad habits.

We've gone through the effort of learning Git/GitHub, Doxygen, UML diagrams, etc. And for some reason, we aren't using Makefiles? Why not provide us with a simple Makefile for every project and explain briefly how it works, and tell the students to update the Makefile with additional source files and header files as needed, and then encourage us to use that. Then the grader only has to type "make" and then he can test our programs. So, rather than requiring a set of files and ONLY those files, we can turn in AT LEAST the required files and any code files needed to compile our programs. This way we are free to design freely and organize our programs in a way which makes the most sense for our implementation.

In earlier projects this was a minor inconvenience, but in the next project, we are given no starter code or guidance for how to design our custom creature, "Best." I would like to put all the creature definitions in files and have a constructor which takes in a filename and reads the creature from the definition. I have no idea how they're planning to test the creatures since they said to just put the definition of the creature in the comments of the code. This doesn't make any sense.

Normally I can get around the strange restrictions the project turn in policy has been putting on us but when we're kept in the dark like this, I feel like it's very likely we're going to lose a ton of points and not know why until it's too late.

Even asking on the class forum for help hasn't yielded any usable information. =[

Pressing forward...

Week 8 - Week of Project Hell (Oct 15 to Oct 21)

This past week has been absolutely awful for me in school. I had Comp Arch, EE Senior Design, and Graphics projects due Monday, Tuesday, and Wednesday respectively. I hardly had enough time to get any one of those projects done, but somehow managed to do it amidst many all nighters AND performing in the University Orchestra concert on Tuesday night.

After finally turning my Graphics project in on Wednesday, I was so used to not sleeping much that I couldn't sleep until 5am. From then until now, I've pretty much been sleeping at around 4-5am, all while trying to get organized and regroup for my Comp Arch midterm on Monday and get my sleep schedule back to normal.

At least I started getting more sleep after Wednesday night, even if it was at an odd time. One drawback of sleeping so late is that you're likely to miss class. Which I did. That's 3 missed quizzes. I have to start treading lightly.

Luckily the material in OOP is starting to feel more coherent and I'm doing better on the quizzes. It's a shame that I missed Friday's quiz because I heard it was pretty straightforward and didn't really cover the reading.

I'll definitely make sure that I'm caught up on the reading by tomorrow morning, though!

Week 7 - Midterm Week (Oct 8 to Oct 14)

Well, this week has been a roller-coaster of good and bad happenings in school. I had two midterms this week, several projects, and an orchestra concert coming up this week (and the week before a performance is always really stressful).

The makeup midterm for OOP was on Monday. I really would have preferred the Friday the day after the original test date, especially since we didn't have class on that day, anyway. I had planned to take the midterm on that day and I was really surprised when it was moved later. I know many people would welcome the chance to spend more time studying, but the problem with moving a midterm closer to another midterm is that you have to spend some of your time studying for each and you don't get as much quality focus time on one thing. Luckily the results were good.

Unfortunately the morning following my late-Monday exam was my graphics midterm. There is only one midterm for that class. Due to a bad test environment (especially the very sick, noisy, and smelly guy that sat next to me for the test and distracted the hell out of me), my grade will be quite bad. I am very worried about that class now and I originally thought it would be totally fine.

Tuesday afternoon and evening, struggle to finish Project 3. It's really hard to know when you're done without good acceptance tests. The unit testing was also rather difficult for this project because you're essentially limited to the common interface with std::allocator. Once you can "cheat" to make everything public and you can test the internals of your implementation, writing tests for it is ridiculous because you have to know how the heap is supposed to look and then check whether it matches. Very very difficult to test, indeed. My normal inclination to be thorough ended up wasting a lot of time because it was hard to come up with things to test.

I've enjoyed the quizzes lately. I did reasonably well on that portion of the test, and we're getting a good look at C++ under the hood. Since I am using C++ in Computer Graphics, I have sometimes wondered if knowing this much about C++ is actually a good thing. I find myself wondering whether the default constructor is good enough and wasting some time trying to get things to work because I implemented a non-default constructor, and lost the default constructor as a result and had to spend time implementing a reasonable copy constructor and copy assignment to make sure everything gets assigned properly. C++ definitely takes a lot of work to really understand what's going on.

Friday was the due date for a big project in computer graphics. I skipped some classes on Thursday and Friday to work on it and finish the whole thing by midnight, and just barely got it working to my satisfaction when it was announced that the deadline was extended 5 days. WHAT? Now I have to spend time catching up on the classes I missed to finish the thing on time, as well as dealing with two new projects (not even counting OOP), and I can't even take advantage of more than a couple hours of the extended deadline. What a waste.

Midterm weeks are terrible. I've got another one coming up, and I don't think I'll even be caught up from last week yet.

Outlook Crashes from Youtube and Google Drive emails

Even though I seem to be the only CS major outside of industry who uses Outlook, I feel like I have to say something about a ridiculous bug related to the fact that Microsoft and Google don't know how to share their toys.

Now, Outlook is an industry standard application. It supports all the standard email formats, and it's got a bundle of cool features besides that. It's more than just an email client. I essentially use it to manage my life, calendar, and contacts.

Google has apparently decided that standard email formats aren't good enough and is now sending emails through its services (Google Docs and YouTube are the ones I've encountered so far) which do something "special." The emails work just fine in web browsers but when opened in Outlook some script or something related to fetching a user's Google avatar causes Outlook to crash.

These videos show the problem and a simple fix:

• http://www.youtube.com/watch?v=eNG2_9yKCPM&list=UU7oZuYX69n34VFHgctJWQPA&index=2&feature=plcp
• http://www.youtube.com/watch?v=QCWcOOBihvY

If you use Google Docs / Google Drive, you'll also have to add docs.google.com to your block list.

I would think that there should be a way you can set up a rule to move these emails to a folder and then set  that folder to display emails in plain text, the way the Junk email folder does, because I don't actually want these emails to be Junk, but this is the only workable solution I have found for now, since it is an incredible waste of my time for my email to crash every so often when I get a new email from one of these services and "open" it by switching to my email tab in Outlook, and finding that the preview pane has tried to display my most recent email, and Outlook has now crashed.

I'm not sure we can expect a patch from Microsoft because they're busy with the next iteration of Office and until this looks like a security hole, it won't be high priority. Google, on the other hand, can cut out the fancy crap and send me the emails I want without all the nonsense scripting garbage.

Week 6 - Pair Programming Round 2 (Oct 1 to Oct 7)

Yesterday, I posted a blog which goes into some depth about const expressions in C++.

Since Andy and I recently encountered an issue with "const" in our project, I will add an extra comment about that here. Note that you can add "const" right before the opening brace of a method declaration, which tells the compiler that the code in that method will not alter the state of the current instance of the class.

Since a[] is an instance member of class Allocator, "bool valid() const {" says that it won't try to modify the values in a[]. Depending on how you write validate, you might run into the situation where the compiler complains about something like:

char* first = &a[0]; // error

So the simple solution to that is instead writing:

const char* first = &a[0];

Note that this is a side effect of the compiler trying to protect you from making unintentional changes to a[] inside of a function which says you won't modify it. In a non-const function, the first version would be okay.

Technically since valid() is a private function, you can change its interface to not say "const", but I would recommend against that because they provided the method stub for us.

Project 3 So Far

---

Going into this project I was a little less enthusiastic going into previous ones, because in CS 439 last semester, I implemented a memory allocator (specifically, a malloc package) using this algorithm (and also a more complex algorithm that uses a O(log(n)) algorithm for selecting which free block to use (to improve performance for a workflow involving many alloc()'s and many free()'s in an arbitrary order)).

Basically, I felt like I had already done this project and that it would be a waste of time.

I'm pleased to say that it definitely wasn't! Working with Andy has been a really pleasant experience. Since I already knew the project really well, I had the opportunity to really slow down and explain how it worked to someone who is really willing to absorb and learn.

Also I have the chance to slow down and make sure that the whole thing is adequately tested and documented.

The cool thing about this project is seeing how templates let us take the same unit tests and apply them to different implementations of the same interface. I like Java generics a bit better in this respect because you can declare a generic with a certain type or interface and any class which subclasses that class can substitute in, but in C++, you don't exactly get that sort of information. As long as you know what you're doing, however, that's not too much of a problem.

One thing which saved us a lot of grief in this project was modularizing the code A LOT and using macros for common "gestures" like finding the header and footer of the previous and next block. Once nice thing about macros is that even though they appear to be functions, they can be used as lvalues as long as the expression works (like you have a pointer p and you have a macro which does *p, which is an lvalue).

I wonder if there is a way to make the return value from a function act as an lvalue. There is probably a trick with references that can be used in that situation.

Convoluted Const Expressions

A past manager of mine once asked me an interview question, for fun. He asked me to describe the type of something like the following:


Boy, am I glad I already had the job! I was totally lost, and at the time, I only vaguely understood his explanation of what it all meant. Of course, it always helps to have a compiler around to fiddle with.

After what we've been covering in OOP class, however, I thought I would have another shot at understanding this cryptic statement.

Not surprisingly, Wikipedia has a wealth of knowledge on the topic. I highly recommend reading through it if you're curious. It discusses how types and pointers are made immutable in several languages.

I also found a more "human" explanation. It's a bit less organized, but you also may find this to be a useful explanation.

Const Data Types

---

So with that preamble out of the way, let's get down to it.

Here's a brief sample, adapted from the blog entry I linked above.


I only want to explain the syntax, below, but these lines are part of a complete file (const.cpp), which shows these types in action. You can compile it and see for yourself.

Here's the intuitive way of looking at the types above:

You can split the whole type statement into two parts.
(1) the part before the star
(2) the part after (and including) the star

If the const is before the star, then it means that the data is constant. If you have a normal type, you cannot alter the data (making it a constant!). If you have a pointer or reference*, you cannot alter the data it points to.

If the const is after the star, it means the pointer is immutable -- you cannot change the address it points to. This means that the pointer is always bound to the same memory address, and you cannot change it, similar in effect to how a reference is always bound to the same location in memory.

* In the case of references, just use the ampersand as the delimiter instead of the star and the same discussion applies. However, placing the const after the ampersand is redundant because you cannot reassign a reference anyway.

I highly recommend playing with the code I linked above (const.cpp) to get a feel for what's going on.

The Interview Question

---

So with that information in mind, I'd like to revisit the interview question. Here is the question again, for reference: "Describe the type of 'ptr' in the following expression:"


We don't quite understand the syntax well enough yet to really answer this question, so let's take it back to const syntax and note a pattern.

When declaring a pointer (rather than its data) as const, you place the const after the star that it refers to. So if that's true, then why don't we also put const after the data type?

Well, actually, you can. These two variables have the same type:


The const keyword can always follow the type it refers to. For pointers, that's the only way you can do it. For the data type you have the option of putting it before or after. Putting it before helps with readability, so that is the preferred style.

Putting it together: a and b have the same type in the code below. c is illegal.


Armed with the new knowledge, let's revisit that interview question:


The last two lines above have the same type and point to n. We were given a, but b might be easier to figure out.

Reading from right to left: we have a pointer to an immutable pointer to an immutable int.

Some popular wrong answers my manager would get include:
1. Constant pointer to a pointer to a constant int.
2. Can you even do that?

#2: Yes you can!

And to be clear, if you wanted to get #1, you could write:



Awesome!