CLASSpp is the C++ version of CLASS, the Cosmic Linear Anisotropy Solving System. This site is meant to be a practical map of the codebase: start from the conceptual pages below, then use the generated API reference when you need the exact class, function, or source-level contract.

‍Looking for tutorials and examples? This page is the C++ API reference. Executed example notebooks and the getting-started guide live on the CLASSpp documentation site.

The code and tests remain the authoritative description of behavior. The Doxygen manual should explain public contracts, ownership and lifetime rules, units, numerical assumptions, and the reasons behind non-obvious algorithms.

Start here

Need	Go to
Understand what documentation exists	Documentation map
Find a C++ type	Class list
Inspect inheritance and the species model	Graphical class hierarchy
Browse source files	File list
Regenerate the manual locally	Updating the manual

Visual maps

Graphviz diagrams are generated for inheritance and directory dependencies. These are the best places to see them:

Graph	Go to
Full graphical inheritance overview	Graphical class hierarchy
Species inheritance tree	BaseSpecies
Non-cold species inheritance tree	NCDMBaseSpecies
Species directory dependencies	species directory
Source directory dependencies	source directory

Architecture map

The high-level computation still follows the CLASS pipeline, but current CLASSpp code uses C++ ownership and module objects rather than the old C *_init() / *_free() lifecycle.

Area	Entry points
Input parsing and normalization	input_module.h, input_module.cpp
Background evolution	background_module.cpp
Thermodynamics	thermodynamics_module.cpp
Perturbations and sources	perturbations_module.cpp
Transfers and spectra	transfer_module.cpp, spectra_module.cpp
Species infrastructure	SpeciesCollection, BaseSpecies, SpeciesInput

Reading the reference

Use Classes when you know the type you are looking for.
Use Files when you are following the execution path through modules.
Use search for input names, species names, and physical quantities.
Treat undocumented generated pages as an index into the code, not as a substitute for the implementation.

Documentation policy

Good Doxygen comments should capture information that the compiler cannot: units, invariants, valid ranges, ownership rules, algorithmic choices, and cross-module contracts. Comments that only repeat the function signature or the next line of code should be removed or replaced with useful context.