There are only two kinds of languages: the ones people complain about and the ones nobody uses.

— Bjarne Stroustrup, creator of C++

Goals

• Familiarize yourself with the C++ syntax
• Make use of the C++ standard library to parse strings
• Follow a strict style guide
• Use Catch2 for automated testing

Getting Started

Get your copy of the assignment here.

Gradescope

You will need to submit your GitHub repository to Gradescope.

Assignment Spec

Design and Style

You should be able to incorporate design feedback from the first week's assignment. However, since we're on a new language, there are some new style guidelines to follow. We follow the Google C++ Style Guide, which we encourage you to skim through before writing your code. We will be rigorously following this style guide. This includes an 80 character line limit and 2 space indents.

Also, we recommend setting up IDE formatting before starting the assignment. You can find instructions here: https://www.jetbrains.com/help/clion/clangformat-as-alternative-formatter.html#enable-manually.

C++

C++ is a semi-object oriented language, and is somewhat similar to Java, except that it derives from C and has different memory management and compilation processes, amongst other things. We teach C++ for the latter half of this class because you will soon be taking CS 225, a class taught entirely in C++.

This assignment focuses on strings, so learning a bit about the C++ std::string object will be useful. The C++ std::vector object may also be useful.

Another important thing to note: C++ does not have a concept of null references/objects like Java does. The only thing that can be "null" in C++ is a pointer, which we have not yet covered in depth. For example, this Java code compiles just fine:

String moderatorName = null;

The above code compiles just fine. The following C++ code will not:

std::string moderator_name = NULL; // Error!
std::string moderator_name = nullptr; // Equally bad!

It is up to you to figure out how to design your code around this restriction.

C++ Header Files

A "header" in C++ is a file that declares the interface of a class. It contains all of the class's method signatures and member variables, but no method bodies.

Futhermore, the method specifications should also be placed in the header file. Someone else should know how to use your class just by looking at the header file, without ever seeing the implementation file.

This is the intuition you should remember regarding header files:

1. .h/.hpp files say "this thing exists, and this is what it looks like" to the compiler
2. .cc/.cpp files say "here's how this thing that I said exists actually functions" to the compiler

You must have both in order for your code to compile!

Specification

The assignment specification is the same as the specification for Java TicTacToe. If the string passed into the constructor is invalid, you should throw a std::invalid_argument exception.

Testing

Much like in the original assignment, this assignment has an emphasis on writing unit tests. Again, you should commit your tests first before implementing any code.

Your tests should be written using the Catch2 testing framework, in the tests/test-tictactoe.cc file. For this assignment, each REQUIRE should be in a separate SECTION, since they are all independent test cases.

To run your tests, select the test-tictactoe configuration from the dropdown next to the run button.

To learn more about Catch2, check out this tutorial.

Main function

Select the tictactoe-evaluator configuration from the dropdown next to the run button. The main function will prompt you to input a board, and then it will print out the evaluation of the board.

Assignment Rubric

For the most part, the rubric is the same as the Java TicTacToe rubric. Here are some things which have changed:

C++

• Headers have inclusion guards (#ifndef or #pragma once)
• All method specifications are in the header class, and operational line comments are left in the source file.
• Code has appropriate namespacing
• Usage of const and references
  • Instance methods that do not modify member variables (the underlying state of the class) are marked as const
  • Parameter passing: Built-in types (such as bool, int, float, etc) are passed by value. Other types (ex: std::string, std::vector) should be passed in as const references when you don't plan on modifying them. It's generally bad design to pass parameters in non-const references to be mutated within a function, because functions should not communicate with each other by mutating parameters. If you absolutely need to pass a variable in to be mutated, pass it in as a pointer.
  • Non-built in for-each loop variables should be declared as const reference when appropriate.
• size_t used in lieu of int where appropriate
• Avoid using namespace std to avoid naming collisions. Instead, only use specific things, e.g. using std::string
• Proper memory management
  • You shouldn't need to worry about this as long as you never use the new keyword, and you shouldn't need to use the new keyword until the linked list assignment.
  • If you do decide to use new (which you probably shouldn't), remember that every call to new must be matched by a call to delete.

Naming and Layout

• Please thoroughly read the Google Style Guide (https://google.github.io/styleguide/cppguide.html), as many naming conventions are different than Java.

Testing

• Taking advantage of the TEST_CASE / SECTION hierarchy to organize tests

Weightings

Your grades for each section of the rubric will be weighted as follows:

• C++ (15%)
• Readability and flexibility of code (15%)
• Object decomposition (5%)
• Documentation (5%)
• Naming (10%)
• Layout (10%)
• Testing (20%)
• Process (10%)
• Presentation (5%)
• Participation (5%)