krzysztof-jusiak
commented
4 years ago Sure, that's possible, I'd actually say [Boost].DI is pretty well suited for the constrained environments as it doesn't require any external dependencies and/or building a library. Regarding, the allocations there are a few customization points which you can take a look into to achieve your goals:
- custom provider (which allows tweaking how dependencies are being created, you can have a custom allocations/none allocations here) -> https://github.com/boost-experimental/di/blob/cpp14/example/custom_provider.cpp
- custom scopes (if you want only a few deps not to be allocated or wanna change the default scope) -> https://github.com/boost-experimental/di/blob/cpp14/example/custom_scope.cpp
- custom policy (if you wanna ensure that deps such as shared_ptr won't be passed via constructors) -> https://github.com/boost-experimental/di/blob/cpp14/example/custom_policy.cpp
I would like to examinate possibility to combine static memory mode to the library - i.e. avoid any regular "new"/"delete" calls in some circumstances.
It can also be achieved with placement new semantics (with explicit destructor calls instead of delete) if memory allocation can't be avoided at all - this only requires buffer parameter at the injector's construction.
My motivation for this feature is cases when Boost.DI is used in memory constrained environment, i.e. embedded platforms (bare metal or RTOS). In such environment it is much cheaper to rely on statically allocated memory buffer (even big enough for all of the generated object tree) than relying on heap / dynamic memory.
What are your thoughts? Is it possible to implement this feature with the current state of the library?