Yes.

Suppose that while calling doSomething() for each actor during a given tick, we create a new actor. Must we call doSomething() for the new actor on the current tick?

It's you choice whether or not you do. Of course, on the next tick, doSomething() will be called on all actors including that new one.

What can I do to be more confident that my program will build for you when you test it and is not likely to have some flaw that will cause it to crash most of the time when you try to run it?

Run our sanity checker on the Linux server. If it tells you you passed the sanity check, then even if you have a lot of things left unimplemented, we will probably still be able to test those features that you have implemented.

Here's what to do:

1. Transfer your Actor.h, Actor.cpp, StudentWorld.h, and StudentWorld.cpp files to the cs32.seas.ucla.edu Linux server.
2. Put those files in a directory where you don't mind if files named Coord.h, GameConstants.h, GameWorld.h, GraphObject.h, Level.h, sanity.cpp, and sanity are created or overwritten.
3. Run the command /usr/local/cs/bin/p3sanity
   This will copy our source files named above into the directory, build an executable named sanity, run it, and tell you whether your program passes or fails the sanity check or silently crashes at some point. (For example, if it gets as far as telling you About to call init and then the program ends with no further message telling you whether your program passed or failed, then something that init did caused it to crash.)

The sanity checker does a simple test to check that loading a level doesn't crash (even if the level contains items you haven't yet implemented), the player (builder cursor) and floors at least are probably put in the right place, the player probably moves left and up correctly, dropping a one way door probably works, and cleanup and destruction of the StudentWorld doesn't crash. This is generally enough for us to test your program without it crashing on almost every case.

Why might a program that appears to work for you crash for us most of the time? It's usually because it relies on undefined behavior. A common issue is either your assuming that a pointer you don't explicitly initialize is null or your intending to initialize it to null and forgetting to do so. On your machine, it might happen to have the bit pattern of the null pointer representation, so it appears to work for you, but on our machine, it might not. Another common issue is StudentWorld::init leaving some StudentWorld int or bool data member uninitialized.

If your program built for you on your machine but doesn't build under g32, it may be that you're doing something that is not Standard C++, such as

• Using setw, setfill, etc., without including <iomanip>
• Using an STL algorithm without including <algorithm>

If attempting to make an actor of type X do something crashes and you can't fix the problem before it's time to submit, that could well make even the first call to StudentWorld::move crash for a level that has a type X object in it. In that case, it's best to have the X object's doSomething just return immediately or perhaps after it does only as much as you know doesn't crash.

Why is the sanity checker reporting memory leaks when it finishes?

Your program is allocating objects with new that it's never deallocating with delete. The likeliest causes are one of these:

• When an actor should be removed from the game during a tick, your StudentWorld::move is doing it incorrectly. Solving problem 1c or 1d of Homework 4 should indicate how to fix the problem.
• StudentWorld::cleanUp is not deleting the player and all other actors.