reactor-cpp
reactor-cpp copied to clipboard
lf-lang
Sdk
What this SDK provides
- Lazy construction of child reactors
- Lazy construction of child reactor banks
- Lazy construction of multi-ports
- Simplified, single line wiring syntax
- Simplified reaction definition, function can be a lambda function or a member function of reactor class
- Parameter definition in the form of metadata for self explanatory reactor parameters as well as configurability via a config map of whole topology
Features missing so far, work in progress
- After delay
- Enclaves
- Physical connection
- Interleaved connection
Building
cd reactor-cpp
mkdir build && cd build && cmake ..
make -j && make install
Examples and Tests examples and test folders have use cases that help understand the concepts.
Immediate next item
- Complete the wiring
- Homogeneous config
- Generate config files (header and source) by SDK
@cmnrd, please review the latest changes, now reactions can only be defined in ReactionInternal class that user would have to inherit from. Once user defines reactions with triggers, dependencies and effects they can not access any other unintended LF entity inside reaction bodies.
State variables would also be defined in this class available to reactions only.
@cmnrd, please review the latest changes, now reactions can only be defined in ReactionInternal class that user would have to inherit from. Once user defines reactions with triggers, dependencies and effects they can not access any other unintended LF entity inside reaction bodies.
State variables would also be defined in this class available to reactions only.
If I understand correctly, this basically replicates the inner class mechanism that is used by the LF code generator. In case of LF, this does work well because the code generator is in full control of defining the scope. Here we are talking about an SDK and the user is in charge of defining the scope and it seems trivial to break out of the intended pattern (both intentionally and by accident). So I am not seeing how the inner class actually helps. Can you elaborate on what exactly is prevented and how?
I am also not sure what LF entities you are referring to. How is LF involved in this?
Yes, it does resemble inner class mechanism. How this differs from inner class
- ReactionChamber centralizes reaction definition with triggers, effects, dependencies and lamdba/member function at a single place in the code (add_reactions function of ReactionChamber class is the place to define all the reactions of the reactor)
- Lets user define reaction body as a lambda function (making sure they still only have access to intended triggers, effects, and dependencies)
With LF entities I meant logical actions, ports and things defined in Users' reactor class, that they want to expose to reactions functions.