Skip to content

MIP++ logo

MIP++

One model, any solver — at raw C API speed.

Get started View on GitHub


MIP++ is a header-only C++23 library for linear, mixed-integer, and quadratic programming — the fastest way to write portable, solver-agnostic optimization models in modern C++. It gives you an algebraic modeling syntax as readable as JuMP or Pyomo, but compiles down to direct calls into the solver's own C API. The same model code targets any of 11 solvers — you choose the backend at compile time, and its shared library is loaded dynamically at runtime, with no link-time solver dependency.

#include <print>

#include "mippp/solvers/highs/all.hpp"

using namespace mippp;
using namespace mippp::operators;

int main() {
    highs_api api;        // loads the HiGHS C API at runtime
    highs_lp model(api);  // swap for gurobi_*, cplex_*, cbc_*, ...

    auto x1 = model.add_variable();
    auto x2 = model.add_variable({.upper_bound = 3});

    model.set_maximization();
    model.set_objective(4 * x1 + 5 * x2);
    model.add_constraint(x1 <= 4);
    model.add_constraint(2 * x1 + x2 <= 9);

    model.solve();
    auto sol = model.get_solution();

    std::println("objective = {}", model.get_solution_value());
    std::println("x1 = {}, x2 = {}", sol[x1], sol[x2]);
    return 0;
}

Where to start

The documentation follows the path of a modeling study: build a model, solve it, read the results, then wrap an algorithm around it.

1. Getting started — read in order, about half an hour.

  • Why MIP++ — the design choices behind the library, why they matter for operations-research work, and who the library is (and is not) for. Start here.
  • Installation — requirements, Conan or CMake setup, and making solver libraries discoverable.
  • A first model — a guided tour of the program above.
  • Coming from gurobipy, JuMP or PuLP — a translation table, and the six things that differ.

2. Modelingvariables and index sets, expressions and constraint families, objectives (including quadratic), special constraints.

3. Solvingstatus, limits and tolerances, solutions, duals and reduced costs, re-solving and model updates.

4. Algorithmsbranch-and-cut with lazy constraints, column generation.

5. Solverschoosing a solver among the 11 backends, and writing solver-generic code for cross-solver experiments.

Complete runnable programs — N-Queens, Sudoku, TSP with lazy constraints, cutting stock by column generation — are indexed in Worked examples.

Supported solvers

Backend LP MILP QP
HiGHS
Gurobi, CPLEX, Xpress, COPT, MOSEK, GLPK
Cbc, SCIP
Clp, SoPlex

Per-feature support (duals, callbacks, MIP starts, …) varies by backend — see the feature matrices in Choosing a solver.

Performance

Time to build the N-Queens model ( binary variables, 6N−6 constraints) — MIP++ in milliseconds, the other interfaces as a multiple of it on the same backend:

N MIP++ HiGHS OR-tools MPSolver OR-tools MathOpt JuMP cached JuMP direct
100 1.6 ms 1.3× 2.6× 3.7× 12.0×
500 37.4 ms 1.3× 3.7× 6.1× 16.1×
1000 151.5 ms 1.3× 5.6× 5.7× 18.3×

A million binary variables in 152 ms through HiGHS, 67 ms through Cbc — and within 2–8% (102–108%) of what the Gurobi C API itself costs. The Python layers land one to two orders of magnitude above that. Build time is noise when a single solve runs for hours — it matters on very large models and in loops that touch the model constantly, and the Performance page is explicit about that scope. Full tables across eight backends, the case where MIP++ loses (SCIP), the limitations and the methodology are there too — benchmark code and raw per-solver timings in mippp_nqueens.

Acknowledgements

This work is grounded in the PhD thesis and postdoctoral positions of François Hamonic, funded by Région Sud and Natural Solutions (PhD grant), the ERC project SCALED (grant n°949812), the PEPR VDBI project RESILIENCE, and Aix-Marseille University's ITEM institute (postdoctoral positions).

Documentation, citing, license