Stubs and Interface

Our goal in this stage is to get the interface for the TreeStringSet class defined as a first step, without implementing any of the functions yet.

Create Placeholder Files

You will need to create and outline the class definitions yourself.

You will be submitting four code files for your homework this week:

• treestringset.hpp
• treestringset.cpp
• treestringset-test.cpp
• Makefile

You should create placeholder (empty) files for each of them now. (And maybe add them to your repo as a starting point.)

Defining the TreeStringSet Interface in treestringset.hpp

The TreeStringSet Class Definition

In treestringset.hpp, define the interface for the TreeStringSet and TreeStringSet::ConstIter, classes as well as your TreeStringSet::Node struct. Use the Specification to identify the names of the public member functions for each class, as well as the using statements that your ConstIter class will need to include. Note that you may end up adding more private member functions and private data members later on.

Global Function Declarations

Your header file also includes one global function: the operator<< function for printing a TreeStringSet to an output stream. Be sure to declare this function outside of the TreeStringSet class definition. The function signature should look like this:

std::ostream& operator<<(std::ostream& os, const TreeStringSet& tree);

Create Stubs for Public Member Functions

A stub is a placeholder implementation of a function; it has the correct signature (parameter and return types) but does not yet implement the intended functionality. Instead, it throws an exception to indicate that it is not yet implemented. For example, a stub for the size() member function of TreeStringSet might look like this:

size_t TreeStringSet::size() const {
    throw std::runtime_error("TreeStringSet::size() not yet implemented");
}

Note that to throw a std::runtime_error exception, you'll need to include the <stdexcept> header file at the top of your treestringset.cpp file.

For each of the public member functions of TreeStringSet and TreeStringSet::ConstIter, create a function stub in treestringset.cpp. Remember that a function stub will have the right signature (parameter and return types), and will throw an exception to say it isn't implemented yet. You will implement each of the member functions in later steps of this assignment.

For now, it's also a good idea to put the following lines at the top of your treestringset.cpp file, just after the includes, so that your stubs can compile without spurious warnings:

#pragma GCC diagnostic ignored "-Wunused-parameter"
#pragma GCC diagnostic ignored "-Wunused-private-field"
// FIXME: Remove these lines when all the functions are implemented

These lines tell the compiler to not warn about unused parameters or unused private data members of your TreeStringSet class, because your stubs won't be using their parameters or any of your class's data members yet (although at this stage, your class shouldn't have any private data members at all).

Create the main() Function for Your Tests

You don't have to write any test cases yet, but you should set up the testing structure in treestringset-test.cpp now with the right includes and a main() function that's ready to call and summarize the tests you'll write in later steps. For the overall structure of the file and what you need to do to use the TestingLogger library, you can look back at your test code from Homework 5 for guidance or refer to the CS 70 Testing Library Help Page.

Create a Makefile

Write your Makefile such that running make generates an executable called treestringset-test. Although you can write your own makefile from scratch, there is a good template on the help page about Makefiles that you can use as a starting point (it is very similar to the makefile you used in Homeworks 4 and 5).

Be sure to have targets for

treestringset-test

which depends on treestringset-test.o and treestringset.o

minispell

which depends on minispell.o and treestringset.o

Because you're using the TestingLogger library code in your program, you'll need to make sure that the linking step(s) in your Makefile include the necessary invocations to include the library in your linked files. The key is to add

-ltestinglogger

in the appropriate places. If you use the template makefile from the help page, it already does what you need.

Compile Your Code

At this point, you can run

cs70-make -H treestringset-test

to build your code. We recommend using cs70-make -H rather than just make, because cs70-make -H will catch more errors if you make a mistake in your Makefile (-H is the --hush option that causes cs70-make to be less chatty about what it's doing and only report actual errors; if you're trying to figure out why something isn't working, you may want to run it without -H to see more details about what it's doing).

If you've used the recommended approach of adding the #pragma GCC diagnostic ignored lines at the top of your treestringset.cpp file, you should not get any compiler warnings related to your stub code (e.g., unused variable warnings) and everything will compile cleanly.

Your test code should be doing nothing at this point, since you haven't written any tests yet, but it should run without crashing. You can run your tests using

./treestringset-test

and see output like this:

All tests passed! Summary of affirmations:
----
Fails   / Total Issue

(It won't list any test groups yet as you haven't written any tests.) If you don't see output like that, compare your code with the code you wrote for Homework 5 to see what you might have missed.

The minispell program should also build, but if you try to run it, it should crash immediately with an exception indicating that some function is not yet implemented (because all the functions are stubs at this point).

You must fix any compiler errors before moving on to the next step. Ideally, you should also have no warnings.

(When logged in, completion status appears here.)