Class CbcCutGenerator

Add a pointer to function member which will allow a client to install their own decision algorithm to decide whether or not to call the CGL generateCuts method. Create a default decision method that looks at the builtin criteria.

It strikes me as not good that generateCuts contains code specific to individual CGL algorithms. Another set of pointer to function members, so that the client can specify the cut generation method as well as pre- and post-generation methods? Taken a bit further, should this class contain a bunch of pointer to function members, one for each of the places where the cut generator might be referenced? Initialization, root node, search tree node, discovery of solution, and termination all come to mind. Initialization and termination would also be useful for instrumenting cbc.

Class CbcFullNodeInfo

While there's no explicit statement, the code often makes the implicit assumption that an CbcFullNodeInfo structure will appear only at the root node of the search tree. Things will break if this assumption is violated.

Member CbcModel::addCuts1 (CbcNode *node, CoinWarmStartBasis *&lastws)

addCuts1() is called in contexts where it's known in advance that all that's desired is to determine a list of cuts and do the bookkeeping (adjust the reference counts). The work of installing bounds and building a basis goes to waste.

Member CbcModel::integerPresolve (bool weak=false)

It remains to work out the cleanest way of getting a solution to the original problem at the end. So this is very preliminary.

Member CbcNodeInfo::numberBranchesLeft_

There seems to be redundancy between this field and CbcBranchingObject::numberBranchesLeft_. It'd be good to sort out if both are necessary.

Class CbcStrongInfo

The notion that all branches are binary (two arms) is wired into the implementation of CbcObject, CbcBranchingObject, and CbcBranchDecision. Changing this will require a moderate amount of recoding.