Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Issue 614 Module & ConfiguredModule (#704)
# Issue 614 Module & ConfiguredModule Fixes #614 (partially) --- # Change Description ## Changes to `Module<>` * Make `Module` independent of Nextsim. It is now a separate Module base class that can be used for any C++ project. * Introduce a `NextsimModule` class that specializes the newly generic `Module` for nextSIM-DG. * Replace `#include "Module.hpp"` with `#include "NextsimModule.hpp"`. * Add a map from interface name to implementation name in the `Module` namespace alongside the `Module` template class. This string-to-string map is not available elsewhere. The data is stored as a function-local `static` variable. * Remove the class-static instance of the reference implementation from the `Module<>` template. This static instance is now a function-local `static` variable, so at least the construction order is well defined. The lifetime is still until the executable epilogue. * Delete the module classes. Where there was originally (for example) a `DiagnosticOutputModule` class that inherited from `Module<IDiagnosticModule>`, everything now refers to the template instantiation. The `…Module` class was necessary to run the register the module at static start-up. With this no longer necessary, * the classes are no longer needed * the class headers (`…Module.hpp`) have been removed * the class header creation script `module_header.py` has been removed * the command in `CMakeLists.txt` to run the header script has been removed. * `#include`s of the `…Module.hpp` file have been replaced with an `#include` of `NextsimModule.hpp` and an `#include` of the interface header file. * Change the API of `Module<>`. It now depends on the definition of two classes before it is `#include`d: * `HelpMap` * `Config` which defines a `std::string Config::getImpl(const std::string&)` function. * There may be a better way to handle this, but more template arguments was much too complex a solution. * Add internal options to set the implementation without setting the unique instance to prevent recursive initialization. The external API remains the same. * Move the class-static data in `Module<>` to be function-local statics. This requires a slight change to the API and a different format in the generated `module.cpp` files. * The `fn` type is now a plain function pointer, rather than a `std::function` object. This required replacing a lambda with an ad-hoc function in one test. * The variables holding the implementation names are now namespaced into `namespace Module::InterfaceClass`. * The necessary changes to `module_builder.py` to support the above changes. * Adds a finalizer method to the `Module<>` template. This will call the destructor on the static instance, allowing all the data arrays the static instance holds to be deleted. ## Changes to `ConfiguredModule` * Remove static data from `ConfiguredModule`. Module configurations are now parsed on demand. * Remove the call from `main` to parse the configuration for the modules. * With the change to lazy configuration, it is impossible to reconfigure modules automatically from the config text. Change to explicit calls to `setImplementation()`. * The `ConfiguredModule_test` now only checks that the module configuration options are parsed correctly. Everything else is handeled by the `Module<>` template class. ## Miscellaneous other changes * Removed the directory `ModuleLoaderTestModules`. These are very defunct. * A fix to `IceGrowth_test`. This is so far from the Module changes, I don't see how it could have been working before. --- # Test Description All unit tests still pass.
- Loading branch information