Each of the first four tasks is between 5 and 10 points each. Task 1 is about 5 points, Task 2 about 10 points, Task 3 about 5 points, Task 4 about 10 points. Task 5 and 6 will be heavier, maybe 30-50 points.

In general, the late penalty is usually not worth it (ten points off per day). So, the basic strategy is to turn in what you can, and fix things up, but not necessarily submit the later version, unless you think you have fixed at least 10 points worth of tasks.

P1 is due Thursday, October 3 at 11 PM. If you have it submitted by Wednesday, October 1, at 11 PM, you get +5 points. If you do the 2 unit tests beyond the required MovieQueueUnit (ItemSortedListUnit counts as one), and have 5 tests each, you get a few more extra credit points.

See the Checklist, before submitting. You should try to compile files such as Tokenizer.o, even if you don't link it. That way we see that it compiles.

Since this isn't that clear from the description, the answer is we'll accept either. Thus, if a box does NOT move at all (because it is immediately blocked), you do not have to print the movement of the box. Therefore, the following is ALSO acceptable.

Player ONLY moves 0 of 1 units EAST
Box at (0,1) is blocked by box at (0,2)
Player is currently at (0,0)

This might lead to the following question: if you intend to print a message about a box regardless of whether it moves or not, when should it be printed? The answer to that is whenever you are pushing a box. Thus, is a player is blocked by a wall, you don't mention a box. However, if a player is moving and the box blocks its way for whatever reason, then you can print information about that box (or, as above, if the box does NOT move, then you don't have to print it at all).

Player ONLY moves 0 of 1 units EAST
Box at (0,1) is blocked by box at (0,2)
Box is moved from (0,1) to (0,1)
Player is currently at (0,0)

Hopefully so. That's why it's still sample.output. Once the errors are gone, they will be the primary.output. Isn't it fun to be active participants in removal of bugs?

No. You can assume each food item has different names ("tea" and "TEA" are the same names, in this case).

Look at the BNF for this answer.

The following question about adding data members and methods to Item was not clear. Yes, you can add data members and methods, such as set and get methods, for Item, however, leave the methods provided to you unmodified (except to implement them, of course), i.e., don't modify the provided public methods' prototypes.

Yes. You may additional data members, and public methods (e.g., write set methods to set values).. However, do NOT delete the other public methods or modify them.

Yes, but there are restrictions. You are expected to implement ItemArrayList and ItemSortedList as described, and to use them in Task 6, as described. You can't substitute, say, a vector for ItemSortedList nor use built in STL container classes (other than perhaps a string) to REPLACE the doubly linked list.

You are NOT allowed to write template classes or to write your own classes using inheritance (except for the unit testing classes), since those are used in upcoming projects.

One goal of the course is to encourage you to read and try out the many functions available in STL, including strings, vectors, algorithms, etc. The skill of looking up APIs, learning how to use library classes, and applying them to a project is quite useful, and is basically how people tend to program in the "real world".

You may wish to point out these ideas to your instructors as you encounter them.

If you're unsure whether you are permitted to use something, you can ask. For now, pretty much any string method in the C++ library is permitted as is using string streams.

There is a sensible answer. Since the size of the array has to be the size passed in from resize(), then if it's smaller that before, it clearly can't hold additional elements. So, you copy over the first N elements where N is the new size.

And that sensible answer is the correct one for this project.

   ostringstream sout ;
   sout << 124 ;
   string s = sout.str() ; // holds 124
   sout.str( "" ) ;  // sets to empty string
   sout << 321 ;
   s = sout.str() ; // hold 321

Return a string for something reasonable (when the string is printed, it should print useful stuff). When you get to Task 6 and begin printing, it will be obvious how to print it out.

Hint: use ostringstream to implement toString().

Warning: toString() should not use print to the screen. It should just return a string.

Yes. As it turns out, ostrstream is part of strstream, which has now been deprecated (meaning, they would prefer you don't use it any more, since they have a newer version), and you should now use ostringstream and #include <sstream> instead.

No. As long as you have consistent style, it's fine to use your own. The exercise is to get you to think about style, for the few students, who may continue to write code in a poor style.

No, but should you want to, you need to #include <algorithm>.

transform takes four parameters: the begin iterator of some list, then end iterator of the same list, the begin iterator of a list (possibly the same one, though could be different), and a plain C function.

It iterates across the first list, and applies the function to the object pointed by the iterator, and copies it to the iterator in the third parameter, and moves up the iterator.

Basically, it's a little like strcpy, except that instead of copying character by character, you call the function on the object, and copy the result of the function across.

So, to convert a string to lowercase:

   transform( str.begin(), str.end(), str.begin(), tolower ) ;

You can also use the code from StringEditor

Unfortunately, I've had problems with making the third parameter with a different string that has a smaller size than str, so be careful if you change the third parameter to an iterator to a different string.

cxx turns out to be a very strict compiler. If Node is private, then any public classes or methods should not be allowed to refer to Node in the parameters or return type (after all, who could declare it? why should a public parameter refer to a private nested class?).

Unfortunately, ConstIterator needs to refer to the Node to initialize it, and ConstIterator is public. Thus, we're forced to make Node public.

First, documentation and commenting are two different things. Comment ALL files you write (the .cpp files).

Write text file documentation on ItemArrayList and ItemSortedList.

Each of these classes contains a main outer class and two nested classes. Thus, you write three parts in each file. For ItemArrayList, write ItemArrayList then ItemArrayList::Iterator, then ItemArrayList::ConstIterator.

Make sure it's easy to determine which class you are documenting.

Sure, why not? Just cut-n-paste.

It's mostly about the important of testing. What you need to do is the following. Copy the files from UnitTestDir and compile. Run to see what it does. See if you can figure out what it does (it adds two tests to a TestSuite then runs each of the tests).

Then, implement MovieQueueUnit (a singly linked list queue unit testing class) in a fashion similar to MovieStackUnit, while also developing MovieQueue. Use MovieStackUnit as a guide (including following what methods to write, and suggestions for tests to run).

You may notice Assert.h has code. This is inlined. It gets compiled when you #include the header into your code. There is no Assert.cpp (because all the code is inlined in Assert.h) to make your life simple.

Essentially, you write tests that use assertTrue and write runTestSuite where you add all the tests you run, and we can test by calling runTestSuite.

List of assumptions you can make:

• You can assume that an opening double quote either has at least one blank space before it, or it is at the beginning of a string.
• You can assume that an closing double quote either has at least one blank space after it, or it is at the end of a string.
• You can assume that an opening single quote either has at least one blank space before it, or it is at the beginning of a string.
• You can assume that an closing single quote either has at least one blank space after it, or it is at the end of a string.
• You can assume that anything in matching double quotes or matching single quotes has at least one non-blank character in it.
• You can assume that a string consisting of only blanks produces no tokens (returns a vector of size 0).
• You can assume there are no escaped characters.

So, the following would not occur: [dog"cat"] ("cat" should have a blank before it), ["cat"dog] ("cat" should have a space after it, [" " cat] (double quotes should contain 1 non-blank character, [ " "] (double quotes should contain 1 non-blank character).

However, this is valid [ ] (returns a vector of size 0).

A token will not consist of any escaped characters (such as \n). When you see the first occurrence of a double quote, you can assume that there will be a matching double quote, which is the next closest double quote afterwards (thus no nesting of double quotes). Similarly, if you see a single quote, it matches the nearest single quote.

There can be double quotes within single quotes, and single quotes within double quotes, but no double quotes within double quotes, and no single quotes between single quotes.

For example, in ["can't*miss"*fun*'see"there'*] (where the brackets indicate the start and end of the string, and asterisks represent spaces), the three tokens are [can't*miss], [fun], [see"there].

Thus, you can't create a token that has single and double quotes.

You can assume no backslashes appear in the string.

It is possible. Let's look at an example. In this case, the dash stands for a blank space so it is easier to see.

""---The-chimp-"-was-'-listening-'-to-"-Dokken""

However, the quotes on the inside are part of the string. The easiest way to create these quotes is to put one line of text in a file using single and double quotes and using getline() to read it in.

You can also write such strings within your program, but then you need to backslash them.

"\"---The-chimp-\"-was-'-listening-'-to-\"-Dokken\""

Notice that the rules are different. When you write strings in a C++ program, you need to write the outermost double quotes, so the compiler knows where the string begins and ends. You also need to backslash (escape) the double quotes on the inside so the compiler doesn't think you are trying to end tyhe string (the compiler will remove the backslashes).

However, if you were writing a text file, you could write the first version at the very top (without the outermost double quotes in red), call getline() and it should read the same string as the second one listed above.

Either way, you would produce four tokens with split():
[----The-chimp-], [was], [-listening-], [to], [-Dokken]
where left and right brackers are being used instead of double quotes to tell you where the string begins and ends (don't use brackets in your output, this is just to make it easier for you to read here).

You are beginning to see how difficult quotes are, because it depends on whether you are writing the string inside your program or in a file. This is actually an important lesson to learn, because if you learn how quoting works (inside the program and outside), you can do more sophisticated things with them (especially in shell and Perl programming).