Model concepts¶

MIP++'s portable interface is specified by C++ concepts, defined in mippp/model_concepts.hpp, except iis_by_deletion_model and deletion_oracle, which come with the headers of the functions they serve. The model concepts describe what every backend of a given problem class provides; the capability concepts describe optional features that vary per backend (see the feature matrices).

Use them to make generic code self-documenting and to fail at compile time instead of at runtime:

template <typename M>
    requires milp_model<M> && has_candidate_solution_callback<M>
void solve_tsp(M & model, const instance & data);

static_assert(has_dual_solution<highs_lp>);

Writing solver-generic code shows the patterns; this page is the catalogue.

Four aliases name the types a model works with, and they are the only portable spelling — model classes declare no public member types:

• model_variable_t<M> and model_constraint_t<M>, the lightweight strongly-typed handles, deduced from what add_variable() and add_constraint(...) return;
• model_scalar_t<M>, the coefficient type (double on current backends), deduced from the variable handle's own linear term;
• model_variable_params_t<M>, the designated-initializer options struct {.obj_coef, .lower_bound, .upper_bound}, deduced from the model's public default_variable_params constant.

Because they are deduced from the API rather than read from a member, any type that provides those functions — a wrapper forwarding to a backend, say — satisfies the concepts without declaring anything else.

Concepts on callback handles¶

A callback handle (the candidate_solution_callback_handle a backend passes to your callback) is not a model: it creates no variables, so the four aliases cannot be deduced from it. The capability concepts that make sense on a handle therefore take a second, defaulted parameter naming the model whose variables and constraints the handle works with:

template <typename T, typename M = T>
concept has_lazy_constraints = ...;   // T is checked, M supplies the types

With one argument the concept applies to a model as usual. With two, the first is the type being checked and the second is the model it belongs to:

static_assert(has_lazy_constraints<
    candidate_solution_callback_handle_t<gurobi_milp>, gurobi_milp>);

// the checked type is inserted first, so the shorthand reads naturally
model.set_candidate_solution_callback(
    [&](has_lazy_constraints<Model> auto & handle) { ... });

The concepts declared this way are has_dual_solution, has_reduced_costs, has_readable_variable_bounds, has_modifiable_variable_bounds, has_readable_constraints and its three finer-grained forms, has_readable_constraint_bounds, has_modifiable_constraint_bounds, has_enumerable_variables, has_enumerable_constraints and has_lazy_constraints. The others describe whole models and stay single-parameter.

Model concepts¶

Solve status¶

get_status() is required by lp_model itself: every model class returns a std::variant over the tag hierarchy of namespace status (optimal and its refinements, infeasible_or_unbounded with its refinements infeasible and unbounded, interrupted, failed, numerical_failure, out_of_memory, limit_reached and its five refinements, unknown). Query it with is<S>(r) (exact tag), is_a<S>(r) (whole branch) and status::solution_available(r); the variant type is model_status_t<M>. is, is_a and the variant_* concepts behind them live in utility/variant.hpp and serve the basis statuses too. Three concepts refine what a given model class can report or do with it:

See Status, limits and tolerances for the hierarchy and how to branch on it.

Limits¶

Each limit concept additionally requires that the matching status::*_limit tag is among those the backend's get_status() can return — a limit you can set is a limit you can detect.

Solution information¶

Infeasibility analysis¶

See Diagnosing infeasibility for both paths, and The deletion filter for the engine on an oracle of your own.

Reading and modifying the model¶

See Re-solving and model updates.

Names¶

Special constraints¶

Neither the SOS nor the indicator functions require a return type. SOS and indicator constraints live outside the linear-row numbering on most solvers, so the constraint handle returned by add_constraint could not designate them; a backend may return a handle type of its own, or nothing, and a solver-generic caller must not rely on one.

Algorithmic building blocks¶

Escape hatch¶

Tolerances¶

Verbosity¶

Expression concepts¶

The expression layer has concepts of its own, defined in linear_expression.hpp and linear_constraint.hpp:

• linear_expression — anything with linear_terms() (a range of (variable, coefficient) pairs) and constant(). Variable handles, xsum results, and operator combinations all satisfy it, and model functions accept any type that does — you can pass your own expression types.
• linear_constraint — anything with linear_terms(), sense() (constraint_sense::less_equal / equal / greater_equal), and rhs().

These are the extension points: a function like add_constraint is written against the concept, never against a concrete expression class. Their sub-concepts — ownership, multipass, and the diagnostics they drive — are covered in Inside the expression layer.