Differential equations stack.
- DiffEqStack() explicit
- Constructor: register differential equations into factory.
- auto selected() const -> std::vector<DiffEq>
- Instantiate selected DiffEqs.
auto tables() const -> std::pair<std::vector<std::string>, std::vector<tk::
- Instantiate tables from which extra statistics data to be output sampled for all selected differential equations.
- auto factory() const -> const DiffEqFactory&
- Constant accessor to differential equation factory.
- auto info() const -> std::vector<std::vector<std::pair<std::string, std::string>>>
- Return info on selected differential equations.
- auto ntypes() const -> std::size_t
- Return number of unique equation types registered.
DiffEqStack:: DiffEqStack() explicit
Constructor: register differential equations into factory.
This constructor consists of several blocks, each registering a potentially large number of entries in the differential equation factory, m_factory, which is of type walker::
Since the functionality of the policies are orthogonal to each other, i.e., they do not depend on each other or their host (the differential equation class), a Cartesian product of combinations are possible, depending on which policies are selected. This constructor registers all possible combinations of policies for all available differential equations. By register, we mean, an entry is recorded in an associative container, a std::map, that associates a lightweight key of type walker::
Since all differential equation types (registered in the factory) "inherit" from a common "base", client-code is unform and generic, and thus immune to changes in the inner workings of the particular differential equations as long as they fullfill certain concepts, i.e., implement certain member functinos, enforced by the common base, DiffEq. The words "inherit and "base" are quoted here, because the common base does not use inheritance in the normal OOP sense and does not use reference semantics, i.e., pointers, visible to client-code either. The relationship is more of a models a-type, which simplifies client-code and allows for the benfits of runtime inheritance with value-semantics which is less error prone and easier to read. See more about the models-a relationship and its implementation in DiffEq/
The design discussed above allows the registration, instantiation, and use of the differential equations to be generic, which eliminates a lot of boiler-plate code and makes client-code uniform.
Details of registration using brigand::for_each and tk::
The template argument to brigand::for_each, as used below, requires a list of list of types. We use brigand::list of brigand::list of types, listing all possible policies, where the inner list must have exactly two types, as the list of lists is constructed from two lists using the cartesian product, and the length of the outer list (the list of lists) is arbitrary. The constructor argument to brigand::for_each is a functor that is to be applied to all members of the outer list. tk::
std::vector<std::vector<std::pair<std::string, std::string>>> walker::
DiffEqStack:: info() const
Return info on selected differential equations.
|Returns||A vector of vector of pair of strings, containing the configuration for each selected differential equation|
DiffEqStack:: ntypes() const
Return number of unique equation types registered.
|Returns||The number of unique equation types registered in the factory|