Package com.ibm.wala.fixpoint
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:
BitVectorVariable,BooleanVariable,IntSetVariable
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 Modifier Constructor Description protectedAbstractVariable()
-
Method Summary
All Methods Static Methods Instance Methods Concrete Methods Modifier and Type Method Description booleanequals(Object obj)intgetOrderNumber()Variables must allow the solver implementation to get/set an order number, which the solver uses to control evaluation order.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 com.ibm.wala.util.graph.impl.NodeWithNumber
getGraphNodeId, setGraphNodeId
-
Methods inherited from class java.lang.Object
clone, finalize, getClass, notify, notifyAll, toString, wait, wait, wait
-
Methods inherited from interface com.ibm.wala.util.graph.INodeWithNumber
getGraphNodeId, setGraphNodeId
-
-
-
-
Method Detail
-
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
-
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>>
-
-