Scippy

SCIP

Solving Constraint Integer Programs

Organization of Source Code

The SCIP source code has different types of files, distinguished by their naming style. The following list gives an overview of the most important file types and their purpose.

SCIP core components

  • Each core component has an implementation with an internal API and a public API.
  • The internal implementation should be in a file <component>.c,h and should not be included in the public API.
  • Internal API functions usually do not take a SCIP* parameter, but a pointer to the component as first argument and pointers to internal structures like SCIP_SET* or SCIP_STAT*, where necessary.
  • The name of internal API functions follows the style SCIP<component><operation>..., e.g., SCIPvarCreateOriginal() or SCIPvarAddLocks().
  • pub_<component>.h declares the functions of the public API that do not need a SCIP pointer. Often, these are getter-functions. For example, pub_var.h contains public variable API functions.
  • Functions in pub_<component>.h follow the same naming style as those in <component>.h and are used by the implementation of the internal API as well.
  • scip_<component>.h declares the functions of the public API that need a SCIP instance (SCIP*), e.g., scip_var.h for public variable manipulation functions. Functions declared in scip_<component>.h are often thin wrappers that call the internal API functions from <component>.h. These functions should follow the naming style SCIP<operation><component>..., e.g., SCIPcreateVarOriginal() or SCIPaddVarLocks().
  • To ensure functions of the public API being reachable in shared libraries, their declaration needs to contain the SCIP_EXPORT attribute.
  • Public types (typedef's, enumerations) are defined in file type_<component>.h. Type names follow the style SCIP_<COMPONENT>....
  • Structs that need to be accessed by several source files are defined in struct_<component>.h. struct_<component>.h is usually included only by <component>.c and maybe scip_<component>.c. Exceptions are due to manual inlining of functions via macros when compiling for optimized mode.
  • All types, structs, and functions are documented with Doxygen-style comments. The documentation of the implementation of a function must repeat the documentation of the function declaration exactly (for doxygen to treat them as identical).

Plugins