Base class for submodules: base_step.

[djmallum]

New submodule base class

base_step name comes from the idea that submodules are steps in a module.

Uses CRTP to avoid v-table overhead. Derived classes are defined as follows:

template<typename data>
class step : public base_step<step,data>
{
public:
    void execute_impl(data& d) const
    {
        // Implementation here
    }
}

data is intended to be the module specific data class derived from face_info.

Derived classses should make use of concepts to enforce getters and setters on data. Example

#include <concepts>
template<typename T>
concept StepConcept = requires(const T& t)
{
    { t.input1() } -> std::floating_point;
    { t.input2() } -> std::integral;

    { t.output1(std::declval<double>()) } -> std::same_as<void>
}

template<StepConcept data>
class step : public base_step<step,data>
{
public:
    void execute_impl(data& d) const
    {
        // Implementation here
    }
}

At the moment, it is recommended to supply everything via functions, even parameters that are set at run time but never changed.

For parameters that are domain wide one could write a function:

const double module::data::foo()
{
    static const double result = cfg.get("result");
    return result;
}

Static ensures that the instance is (a) uniform per instance of data, and (b) set once (thread safe).

It does involve a hidden bool and if check that is evaluated at runtime on every call.

Parameters that are per-face must have a private variable. Designing submodules derived from base_step with getters and setters provides flexibility for the writer.

Future work

Following this, can merge:

1. A data base class. This base class could be combined with face_info. It has three uses: (1) providing a constructor for the data class to accept a mesh_elem, config_file, and global object. Allows for more detailed control and access to configuration, inputs/outputs, and global variables for submodules. (2) provide a caching system to ensure that inputs and outputs (depends/provides) only dereference the mesh_elem object once per time-step, with minimal overhead by the user and memory savings between timesteps. (3) A flexible and inline-able interface for accessing inputs and setting outputs.
2. Submodules derived from base_step
3. Modules using these submodules.

[Copilot]

Pull request overview

This PR introduces a new base class base_step for submodules using the Curiously Recurring Template Pattern (CRTP) to avoid virtual table overhead. The class provides a compile-time polymorphic interface where derived classes implement execute_impl and the base class provides the execute method that dispatches to the derived implementation.

Key changes:

• Introduces CRTP-based base_step class template for building submodules
• Uses C++20 concepts to enforce that derived classes implement the required execute_impl method
• Designed to support a modular architecture where submodules are composed as steps in a processing pipeline

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[djmallum]

Lemme tell you... That's neat.

Most of these are good suggestions that I can resolve tomorrow.

[Chrismarsh]

I haven't tried it before here. Figured might as well have another hot take.

[djmallum]

Updated

[djmallum]

Closed and now merged with #155