ILOG CPLEX 11.0 User's Manual > Advanced Programming Techniques > Using Goals > Memory Management and Goals |
Memory Management and Goals |
INDEX PREVIOUS NEXT |
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.
Copyright © 1987-2007 ILOG S.A. All rights reserved. Legal terms. | PREVIOUS NEXT |