Class AbstractVariable<T extends AbstractVariable<T>>
java.lang.Object
com.ibm.wala.util.graph.impl.NodeWithNumber
com.ibm.wala.fixpoint.AbstractVariable<T>
- All Implemented Interfaces:
IVariable<T>, INodeWithNumber
- Direct Known Subclasses:
AbstractIntRegisterMachine.MachineState, AbstractIntStackMachine.MachineState, BitVectorVariable, BooleanVariable, IntSetVariable, NullPointerState, ParameterState, PrefixVariable, TypeVariable
public abstract class AbstractVariable<T extends AbstractVariable<T>>
extends NodeWithNumber
implements IVariable<T>
Represents a single variable in a fixed-point system.
-
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptionbooleanintVariables must allow the solver implementation to get/set an order number, which the solver uses to control evaluation order.final inthashCode()static intnextHash()I know this is theoretically bad.voidsetOrderNumber(int orderNumber) Variables must allow the solver implementation to get/set an order number, which the solver uses to control evaluation order.Methods inherited from class NodeWithNumber
getGraphNodeId, setGraphNodeIdModifier and TypeMethodDescriptionintA non-negative integer which serves as an identifier for this node in it's "dominant" graph.voidsetGraphNodeId(int i)
-
Constructor Details
-
AbstractVariable
protected AbstractVariable()
-
-
Method Details
-
equals
-
nextHash
public static int nextHash()I know this is theoretically bad. However,- we need this to be extremely fast .. it's in the inner loop of lots of stuff.
- these objects will probably only be hashed with each other
AbstractVariables, in which case incrementing hash codes is OK. - we want determinism, so we don't want to rely on System.identityHashCode
-
hashCode
-
getOrderNumber
public int getOrderNumber()Description copied from interface:IVariableVariables must allow the solver implementation to get/set an order number, which the solver uses to control evaluation order.It might be cleaner to hold this on the side, but we cannot tolerate any extra space. TODO: consider moving this functionality to a subinterface?
- Specified by:
getOrderNumberin interfaceIVariable<T extends AbstractVariable<T>>- Returns:
- a number used to order equation evaluation
-
setOrderNumber
public void setOrderNumber(int orderNumber) Description copied from interface:IVariableVariables must allow the solver implementation to get/set an order number, which the solver uses to control evaluation order.It might be cleaner to hold this on the side, but we cannot tolerate any extra space. TODO: consider moving this functionality to a subinterface?
- Specified by:
setOrderNumberin interfaceIVariable<T extends AbstractVariable<T>>
-