gko::config::registry#
Lookup table for externally-supplied named objects that the
configuration document can refer to by string key. Without the
registry, every operand of a configured factory would have to be
inlined in the document — with it, the application can construct
e.g. the system matrix in C++ and have the document say
"system_matrix": "A".
Ginkgo ships built-in keys for the standard LinOp, LinOpFactory,
and CriterionFactory types. Applications can extend the registry
with their own LinOpFactory subclasses by passing an
additional_map to the constructor; the convention is to prefix
user-supplied keys with usr:: to avoid clashing with Ginkgo’s
namespace.
gko::config::registry reg;
reg.emplace("A", system_matrix);
auto factory = gko::config::parse(pnode, reg, type_desc);
-
class registry#
This class stores additional context for creating Ginkgo objects from configuration files.
The context can contain user-provided objects that derive from the following base types:
LinOp
CriterionFactory
Additionally, users can provide mappings from a configuration (provided as a pnode) to user-defined types that are derived from LinOpFactory
Public Functions
-
registry(const configuration_map &additional_map = {})#
registry constructor
- Parameters:
additional_map – the additional map to dispatch the class base. Users can extend the map to fit their own LinOpFactory. We suggest using “usr::” as the prefix in the key to simply avoid conflict with ginkgo’s map.
- registry(
- const std::unordered_map<std::string, detail::allowed_ptr> &stored_map,
- const configuration_map &additional_map = {},
registry constructor
- Parameters:
stored_map – the map stores the shared pointer of users’ objects. It can hold any type whose base type is LinOp/LinOpFactory/CriterionFactory.
additional_map – the additional map to dispatch the class base. Users can extend the map to fit their own LinOpFactory. We suggest using “usr::” as the prefix in the key to simply avoid conflict with ginkgo’s map.