Hunter Liu's Website

13. Week 7: Midterm

This week’s classes have been/will be dedicated to walking through the midterm practise problems posted on BruinLearn. In the processes of solving these, however, I realised that there are some things about C++ that one needs to know to solve the problem, yet were not formally addressed during our classes. Some of these are even beyond the scope of what we need to know for PIC 10A, but they provide important context as to why some things are the way they are.

Before that, I’d like to list a few resources that may be useful in preparing for the “written” portion of the exam, where you may be asked to write code. As languages are best learned by immersion, coding is best learned by experience.

• Project Euler has a collection of wonderful mathematics problems that are generally doable by hand, but infeasible due to scale. A majority of these problems are far too difficult for this class, but I think the first 50 problems or so (not all of them) are at an appropriate level. If any of them look too hard, just skip them.
• Advent of Code is an annual coding event/competition. From the first of December up to Christmas, one problem is released each day. The problems get progressively harder, and so the first handful of problems each year are at a good level for this class.
• LeetCode is primarily used to prepare for techinical interviews, so many of their problems are not aimed at students of our level. That being said, they do have some beginner-friendly problems and sections.

What follows is a broad collection of generally unrelated remarks about things we haven’t covered in class. I am not in charge of the midterm, and I do not know if any of these concepts will appear or be relevant. I am including them here because I think they’re very relevant to coding in C++ in general, regardless of if you take this midterm.

Compilation Errors vs. Warnings

As we learned back in week 1, a compilation error is when the compiler fails to make heads or tails of the code you’ve typed. However, there are a variety of statements that will compile despite being nonsensical, redundant, or logically incorrect. The compiler is sometimes capable of identifying such code, and it will warn you that human beings should not be writing such code without a very, very good reason.

Note that warnings are compiler-dependent: some compilers will warn you about some things while others will warn you about other things. Even within compilers, they may suppress certain warnings based on the user’s settings.

Here are some examples:

• if(x == 0); x += 5;
  This is surprisingly valid code, but it almost certainly doesn’t do whatever the user was intending. The compiler may issue warnings for this. Try to figure out what this does!
• while(--x) {}
  Some compilers will warn you about empty loop bodies. This loop will actually decrement x until it reaches 0.
• int l = s.length(); (here, s is a string)
  The length of a string (and the size of a vector) is technically a size_t type variable, not an integer. This is valid because the compiler will implicitly convert the size_t into an int, but it may issue a warning because of potential overflow. Similarly, some compilers will warn you about implicitly casting double variables into int’s.

Here’s an extended example:

1int foo() {
2    return 5; 
3    return 6; 
4}

The second return statement will never ever be run, no matter when or how foo() is called. While the above is syntactically valid, the compiler may warn you that some of the code you’ve written is unreachable.

When do I need using namespace std;?

Throughout this course, we have had the stubborn policy of always typing the line using namespace std; at the start of our programs, but we’ve never really explained what it’s for.

C++ is a pretty large language, but the compiler can only know so many words. While it recognises the terms int, return, and for, and although it understands symbols like (), [], {}, and arithmetic operators (among many, many others), it doesn’t by default understand what cout, string, and vector mean.

These words are provided by libraries, or bundles of code written by other people. C++ comes with a set of standard (std) libraries, including iostream, string, and vector, which provide a bunch of helpful utilities that the base language doesn’t have.

C++ has a lot of libraries, and this can cause issues when they start using more and more names for things. For instance, what if you’re coding a project involving some complicated linear algebra, and you need to make a variable called vector? How does the compiler distinguish this from the standard library’s vector?

The answer is the namespace (akin to packages in Python and Java). All of the standard libraries belong to the std namespace, and to use the tools that they provide, one must (usually) explicitly tell C++ that you’re borrowing a tool from the std namespace:

1#include <iostream> 
2
3int main() {
4    std::cout << "Hello world!" << std::endl; 
5    return 0; 
6}

However, typing std every time you need a string or every time you print sometihng out will erode your joints. We get around this by typing using namespace std; at the start of the program! This tells the program that we’re be using tools from std throughout the entire program, thus alleviating the need to spam std:: in front of every other statement.

Strings: substr, size, and length

We’ve learned about strings before, but we didn’t cover the entire library in detail. I received several questions about the difference between size and length, so I should clarify that these both work on strings, and they do the exact same thing: they tell you how many characters are in the string.

Another question I got was about the substr function, which stands for “substring”. It cuts out a portion of a string. You can read more about it on the C++ reference. In short, the substr function takes two arguments: the first is the starting index of the string, and the second is how many characters to take. If there aren’t enough characters in the string, it just stops at the end. If the second argument is omitted, it goes to the end of the string. For instance:

1// H e l l o _ w o r l d  !
2// 0 1 2 3 4 5 6 7 8 9 10 11
3string s = "Hello world!" 
4cout << s.substr(6, 5) << endl;   // world
5cout << s.substr(10, 15) << endl; // d! 
6cout << s.substr(3) << endl;      // lo world

The string’s indices are labelled at the top, and the outputs are labelled in the comments.

Strings and Vectors: .at() vs. []

During my discussions, I have only been using .at() to access specific elements of a string or a vector, but there is another way to do the same task. Instead of typing s.at(index) or vec.at(index) for a string s or a vector vec, one may type s[index] or vec[index] to do almost exactly the same thing.

There is a slight distinction, and it’s what happens when the index is not valid. Perhaps the index is negative, or perhaps it’s past the end of the string or vector, and this may happen if one asks the user for an input. In this situation, using [] will cause the program to crash immediately, and there is nothing one can do to stop it. On the other hand, using .at() allows one to detect that an error has occurred from within the program, then handle the error appropriately (perhaps by insulting the user).

Specifically, this is because .at() will throw an exception when it receives bad input. You can then “catch” the exception before it crashes the program and respond to it. Again, this is a luxury that [] does not afford you, and for this reason, .at() is considered to be safer than []. If you take PIC 10B or PIC 10C, you will probably learn more about this.