//if any subgoals remain, process the one at the front of the list
//grab the status of the frontmost subgoal
int StatusOfSubGoals = m_SubGoals.front()->Process();
//we have to test for the special case where the frontmost subgoal
//reports "completed" and the subgoal list contains additional goals.
//When this is the case, to ensure the parent keeps processing its
//subgoal list,the "active" status is returned
if (StatusOfSubGoals == completed && m_SubGoals.size() > 1)
//no more subgoals to process - return "completed"
This method clears the subgoal list. It ensures that all subgoals are
destroyed cleanly by calling each one’s
Terminate method before deletion.
template <class entity_type>
for (SubgoalList::iterator it = m_SubGoals.begin();
it != m_SubGoals.end();
NOTE Some of you might be wondering how atomic goals implement the
AddSubgoal method. After all, this method is meaningless in this context
(because an atomic goal cannot by definition aggregate child goals), but it still
has to be implemented in order to provide the common interface we require.
Since clients should know if a goal is composite or not and therefore
shouldn’t ever call
AddSubgoal on an atomic goal, I’ve chosen for the method
to throw an exception.
386 | Chapter 9