Creating the IProgram Subclass

Function/Role

An instance of an IProgram subclass represents a single individual in a population of individuals which are evolving against some problem. Consequently this is a central class and along with the IPopulation subclass it contains most of the functionality of an instance of VUWLGP. Primarily this class is responsible for:

  1. Managing the memory of the instructions which constitute this program.
  2. Caching the final register values it produced for the fitness case it last executed against.
  3. Providing functionality for executing a program, updating its fitness as a result etc.
As with other classes it is recommended that users of VUWLGP read the source code of the existing implementations of IProgram, e.g. MultiClassProgram.


Constructors and the Copy Constructor

The constructor of a program has two responsibilities. It should pass a pointer to a fitness measure to the IProgram constructor, and this memory will then be managed by its destructor. It should also create each of the instructions, ideally using its InstructionFactory method, for consistencies sake as this method is what is used elsewhere. The subclass will also need to implement a deep destructor and copy constructor.


static Instruction<T>* InstructionFactory()

This method should be abstract but unfortunately that isn't possible in C++ (yey for a broken and rather decrepit object model), hence the basic implementation in IProgram throws an exception. All that the reimplementation of this function needs to do is return a pointer to a new instruction, using whichever instruction class this class of program should use. The memory for these instructions is then managed and deleted in IProgram::~IProgram.


std::vector<Instruction<T>*>& RawAccessToTheInternalInstructions()

This method does not need to be reimplemented in any subclass - it is only mentioned here because it so blatantly violates object encapsulation. Thus, an explanation.

Evolutionary operations are members (and would ideally be mixins and so just friends) of IPopulation and its subclasses. This is because they need internal access to the private members of populations so that the resulting programs they create can replace existing ones.

However, they also need access to the private members of IProgram and its subclasses - else how would they change part of a program? Each such function could be made a friend, but since friendship isn't inherited this would be clunky and frustrating to use. Hence this function, which at least has a clunky and blatantly evil name. It should only be necessary to use this method and it's const partner ConstRawAccessToTheInternalInstructions in evolutionary operations.



Christopher Fogelberg
fogelbchri@mcs.vuw.ac.nz or cgf.unimail@syntilect.com