OK, apparently, cxx gets confused figuring out that the type of an iterator is indeed a type. The easy solution appears to be to add the keyword "typename" in front of the declaration of the iterator variable, which tells it "the following is a type".

typename  BstSortedList< Pair<First, Second>, PairComparator<First, Second> >::ConstIterator iter ;

Once this is done, then hopefully, you will not need to create BstNNS.

IGNORE THIS ANSWER, look above

Alas, something odd with the cxx compiler. The solution that one student has found (it's not great, but is OK) is the following. Compile the code associated with the BstMap without using the strict_ansi option (just leave it out).

Unfortunately, to link the BstSortedList properly, you need to remove std:: from the .h files.

So, the solution, which is kind of kludgy, is to create a copy of BstSortedList.cpp and BstSortedList.h, and rename them to BstNNS.cpp and BstNNS.h (where NNS stands for No NameSpace), and do a search-and-replace of both files (actually, there's no need to rename the classes within these files, just get rid of namespaces in them).

We can then run drivers on BstMap with BstNNS without the strict_ansi option (the rest of your code will be compiled with the strict_ansi option). If you have a (MUCH) easier solution that doesn't require using a different compiler, then send email. For now, use this solution.

The problem is new, and seems to be some problem with the upgraded cxx compiler, which was installed at the beginning of the semester. This was not a problem last semester under the older cxx compiler.

This solution was proposed by a student who played around with the compiler options until finding this solution. (Other solutions would be to use g++, but then it doesn't handle templates as cxx does).

Yes. Read Project 3 updates (links from the P3 webpage).

It refers to all nodes that are "descendants", but not including the node itself. Thus, if x has left child y, and y has left child z, then the "proper" descendants of x are y and z. The terminology is analogous to "subset" versus "proper subset". (Thus, "descendants" often include the node itself as a descendant).

If you are a math person, this is the Kleene closure of the child relation.

Not exactly. Think of the "single subtree pullup" as a rule that should be applied if a single subtree exists. If it doesn't exist, then then rule isn't applied. To be fair, it would be nicer if the problem used that rule, but just do the problem as is.

No. Otherwise you could completely avoid recursion by simply calling helper functions with loops. Yes, technically, a recursive function is one that calls itself directly or indirectly, and could, in addition, have loops, but for the purposes of the project, we'll define a recursive function as one that does not have loops in it, and may call a helper function which follows the same definition.

Thus, the helper function must then be recursive (i.e., contain no loops) which can either call itself, or call another helper which is itself recursive.

Doesn't matter. MovieBstSortedList appears in the posting account, and you can use that as the start of your binary search tree (using Movie class from P1).

Once you templatize MovieBstSortedList into a template class, you can make it into BstSortedList<Item, ItemComparator> (or whatever you need).

However, you should do the UNIT testing on BstSortedList<Movie, MovieComparator> (but the actual game project on BstSortedList<Item, ItemComparator>). You may need to define MovieComparator (do it in the same way as ItemComparator).