Upload Your Planning Images with the Right Names and Formats

To get credit for your images, you need to provide your picture files in the right format and with the exact names that we (really the autograder) are expecting, including capitalization, spacing, file extension, and so on. You also need to put the file in the correct directory and git add, git commit, git push to make sure the file(s) end up in your GitHub repo.

Although we haven't tracked down exactly how it occurs, sometimes when students upload images from the command line with git, the images don't get uploaded properly. So it's important that you check your images in the GitHub web interface to make sure they're there and that you can view them. You can also upload images directly using the GitHub web interface rather than using the command line.

Testing Suggestions

You can't test all of push_front()'s behavior until pop_front() is also working, but you can test some of it. Being able to test push_front() (a bit) before you've even written pop_front() is (arguably) a good thing.

But push_front() and pop_front() clearly have a relationship, so testing them together makes sense.

Don't Test Improper Use

Users are never supposed to call pop_front() on an empty list. If they break this rule, they get undefined behavior.

A different team might have put assert(!empty()); at the top of pop_front(), to check its precondition, and assert just crashes the program if the assertion fails.

You Can't Explicitly Test the Destructor

If your destructor doesn't work properly, you'll see problems with memory leaks running under Valgrind. But if you've coded it as we suggest, the code should be so simple that it doesn't need much testing anyway.

Double Check Your Tests

When writing tests, make sure you call summarize at the end of the function and return the result!

Also remember to add the appropriate function call(s) to the main function in intlist-test.cpp, so your tests actually get run.

Notes

new and delete

A good rule of thumb is “when you write new, figure out where the delete should go”. If your code for push_front creates a new list node with new Node{val, ptr}, where should you be putting a corresponding delete to mirror that new?

All Nodes are on the Heap

Don't create Node objects on the stack. When you make Nodes, you need to be using new.

Writing the Destructor

In general, a good way to code is to try to avoid writing “tricky” code. The job of the destructor is to get rid of all the data in the list. You could write an explicit loop that calls delete, but doing that gives you two places where you have a delete and only one with a new, which is a bit asymmetric.

Instead, it's better to just use the code you have. Your job is to throw everything in the list away, and you can just pop things off the list until it's empty. The code for doing that should be very simple and thus obviously correct.