ILOG CPLEX 11.0 User's Manual > Advanced Programming Techniques > Using Goals > Memory Management and Goals

Java and .NET use garbage collection to handle all memory management issues. Thus the following applies only to the C++ library. Java or .NET users may safely skip ahead to Cuts and Goals.

To conserve memory, in the C++ API, ILOG CPLEX only stores active nodes of the tree and deletes nodes as soon as they become inactive. When deleting nodes, ILOG CPLEX also deletes the goal stacks associated with them, including all goals they may still contain. In other words, ILOG CPLEX 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.

ILOG CPLEX 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 the C++ API of ILOG Concert Technology. Instead, ILOG CPLEX 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, you see that the 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 arguments of the Or goal. ILOG CPLEX takes over memory management for these two constraints as soon as they are enclosed in a goal. This takeover happens via the implicit constructor IloCplex::Goal::Goal(IloRange rng) that is called when the range constraints are passed as arguments to the Or goal.

In summary, the user is responsible for calling end on all ILOG Concert Technology objects created in a goal, except when they have been passed as arguments to a new goal.

Also, user code in the execute method is not allowed to modify existing ILOG Concert Technology objects in any way. ILOG CPLEX 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.