The class is over! And with it, this blog. What follows are my thoughts on this class as a whole. It’s been a hell of a ride.

Lectures

Lectures were dense and focused in scope. We wrote C++, we compared it to Java, and we wrote more C++. They went by quickly, and there was often a “big reveal” (high point of the god-damn class) near the end that kept me engaged. Missing class can quickly snowball into bad (quiz) grades, so don’t do it.

It’s fun being put on the spot to dissect blocks of code presented to the class, at the risk of minor embarassment for answering questions incorrectly. I’ve noticed Professor Downing tends to call on the same group of students often, perhaps in an effort to make sure they’re paying attention. On occasion, questions about new or tougher concepts are targeted to those sitting in the front (who are also probably doing well in the class), and for those, there’s no shame in answering incorrectly, which is nice.

A lot of C++ concepts overlap with each other, and it’s important to understand the exact terminology given for each idea. A pointer and reference are similar in some ways and not in others. A copy constructor and a copy assignment are easy to mix up. I appreciate Professor Downing being pedantic about vocabulary and sematics, because it can make a big difference with what you say and what you mean.

Projects

The projects are all interesting. They require writing the C++ that we’ve learned in class, no real surprise there. None of them are terribly difficult, though fixing bugs along the way and adhering exactly to the spec can be stressful. I’ve already talked about them in prevoius posts, so I won’t go into detail on any one specific project.

A large fraction of the project work, perhaps 40%, was actually “overhead” - tasks that weren’t directly writing implementation code. This included unit tests, documentation, continuous integration, and other project requirements. Unfortunately, some tools we used often felt more like an added burden to carry, rather than a real benefit.

Travis CI is… nice, I suppose, until the build fails because of some external third-party repository going down. Doxygen is… a novelty, given the scope of our projects. clang-check can be unnecessarily annoying at times. Google Test, Valgrind, and Make were all pretty useful though; I’m glad we used those.

Exams

We only had two exams throughout the semester. Both exclusively involved writing code (in C++). Exams are taken in person on Canvas, which sadly, has a text editor worse than Notepad. The first exam was straightforward, fair, and a good reflection of the material we had learned so far in class and from the projects.

The second exam, however, was significantly more difficult. It covered a much broader scope of topics, and had more problems despite having the same time limit as the first. There were also a few surprises, and, to my knowledge, certain assumptions had to be made about C++ behavior that were never taught. That wasn’t fun.

I would much prefer having three exams throughout the semster than two, so there is less opportunity to have gaps in knowledge going into the exam.

Conclusion

I’m going to miss this class! I went in knowing absolutely no C++ whatsoever, and now I have (a decent amount of) confidence with the language. There’s still plenty more about C++ I don’t know, and I am eager to go out and learn more. I’m also much more confident with OOP principles in general.

That said, this class isn’t perfect, and there’s a lot that can be improved upon. I feel that too much of our grade is dependent on tiny details here and there, and missing them is more of a human problem than a material one that can be solved by repetition. Though, I do believe that, as a student, the raw amount of knowledge I’ve gained from this class far outweighs my complaints here and there.

Thanks for reading, and have a great winter break!