I envisioned play() doing the following:

• get's Robot's and Stalker's positions
• calls searchList() to get vector of moves reachable by Robot
• get's best move for Robot
• updates Robot's points
• moves Robot
• puts 0 in cell she used to occupy
• moves Stalker
• puts 0 or negative points back in cell he used to occupy
• refreshes the board

No! This is not contradictory. The Board still has positive values and the Robot still has valid moves. So the Robot keeps moving, even if it is to a cell with 0 points, in order to reach a cell with + points on a subsequent move or moves.

Let's assume that the robot will have enough valid moves in the cdll to get (eventually) to the cell with points. This will only work IF you are always choosing the first move in the list that results in the same number of points AND you are always choosing the reachable move with the maximum number of points. (Sometimes the max points will be 0.)

The argument is superfluous but we will keep it in there for project 2.

Yes.

Perhaps I should begin with Board's play(). In play, we do the following:

The reason we no longer use the g++ compiler for your projects is due to the strange way templatized classes must be handled there. If you have a Foo class (with a Foo.h and a Foo.cpp) and Foo is templatized, you need to do the following in Foo.h ONLY FOR THE g++ COMPILER:

    #ifndef FOO_CLASS
    #define FOO_CLASS

    template
    class Foo {

    ...

    };

    #include "Foo.cpp"

    #endif FOO_CLASS

After you have determined which move is the best one (it is the one that is within range of the robot and has the highest points) it will be an Mpair. You change the robot's position (and change the number of points the Robot has, if the cell the Robot moves to has contents != 0).

The comments on this function were meant to be an example. I cannot tell you what each direction means because it depends upon what is in the Moves cdll and where the Robot is located. You need to write the function that will be able to make the correct move irregardless of these caveats.

According to Chris, it has to do with type nesting. So while you can do this:

    vector<Pair>::iterator it = pairs.begin();
     and
    typename vector<T>::iterator it = pairs.begin();

your cannot do:

    vector<T>::iterator it = pairs.begin();

One of your TAs, Michael, who is implementing this project, had several suggestions that I incorporated into P2. Most involve correcting or expanding upon comments. One was an added method to Pair.h (the overloaded = =).

We feel that this will help your understanding and ease your pain (of implementation.)

Your TA Chris has the following suggestions:

Remove all .o, cxx_repository/, tarballs, core, and executables from all of the project directories. You should LEAVE your .cpp, .h, test input/output files, and makefiles there

You should have enough space to keep all of your old project header, implementation, makefiles, and input/output files. The only large amount of space will be core dumps and executables. If you feel like you should clean out your directories, tar and gzip your directory and ship it to another computer.
tar -zvcf px.tar.gz px/ will tar and gzip the tar for all files in px/ into px.tar
tar -zvxf px.tar.gz px/ will untar and gunzip all the files from px.tar into a directory px

If you are not debugging at all, or you do not use the ladebug debugger, remove the -g flag. Also, if you are not using a debugger, the core dump is useless. You can safely:
limit coredumpsize 0
Core dumps are usually large, and this will stop the executing environment from creating a core dump.

Only make executables you are testing.

Use subdirectories. The compiler can be tricked into thinking it has more memory than it does if you work from a subdirectory.

If none of the above works, you can do a temporary fix but you must do this every time you log into your bt214 account. Type:

unlimit filesize