Memory Management and Goals
Java uses garbage collection to handle all memory management issues. Thus the following only applies to the C++ library. Java users may safely skip ahead to Cuts and Goals.
To conserve memory, IloCplex only stores active nodes of the tree and deletes nodes as soon as they become inactive. When deleting nodes, IloCplex also deletes the goal stacks associated with them, including all goals they may still contain. In other words, IloCplex takes over memory management for goals.
It does so by keeping track of how many references to every goal are in use. As soon as this number drops to zero (0), the goal is automatically deleted. This technique is known as reference counting.
IloCplex implements reference counting in the handle class IloCplex::Goal. Every IloCplex::GoalI object maintains a count of how many IloCplex::Goal handle objects refer to it. The assignment operator, the constructors, and the destructor of class IloCplex::Goal are implemented in such a way as to keep the reference count up-to-date. This means that users should always access goals through handle objects, rather than keeping their own pointers to implementation objects.
Other than that, nothing special needs to be observed when dealing with goals. In particular, goals don't have end() methods like other handle classes in ILOG Concert Technology. Instead, IloCplex goal objects are automatically deleted when no more references to them exist.
Local cut goals contain IloRange objects. Since the IloRange object is only applied when the goal is executed, method end() must not be called for a range constraint from which a local cut goal is built. The goal will take over memory management for the constraints and call method end() when the goal itself is destroyed. Also, an IloRange object can only be used in exactly one local cut goal. Similarly, method end() must not be called for IloRangeArray objects that are passed to local cut goals. Also such arrays must not contain duplicate elements.
Going back to example ilogoalex1.cpp, we see that method end() is called for the temporary arrays x, obj, and feas at the end of the execute() method. Though a bit hidden, two IloRange constraints are constructed for the goal, corresponding to the parameters of the Or goal. IloCplex takes over memory management for these two constraints as soon as they are enclosed in a goal. This happens via the implicit constructor IloCplex::Goal::Goal(IloRange rng) that is called when the range constraints are passed as parameters to the Or goal.
In summary, the user is responsible for calling end() on all ILOG Concert technology object created in a goal, except if they have been passed as parameters to a new goal.
Also, user code in the execute() method is not allowed to modify existing ILOG Concert Technology objects in any way. IloCplex uses an optimized memory management system within goals for dealing with temporary objects. However, this memory management system cannot be mixed with the default memory management system used by ILOG Concert Technology. Thus, for example, it is illegal to add an element to array vars in the example, since this array has been created outside of the goal.
