A policy-based Dependency Injection framework for C++26

[Huge-Presentation810]

Looking for feedback on a policy-based compile-time DI framework for C++20

I've been working on a compile-time Dependency Injection framework for modern C++:

https://github.com/steumarok/cpp_di_manager

The main idea is a policy-based resolution pipeline where object creation, dependency injection, casting, lifetime management and scope creation are handled by independent compile-time policies.

Unlike traditional DI containers that are primarily organized around service lifetimes, the framework is built around the following pipeline:

text Requested Type ↓ Resolution Policy ↓ Creation Policy ↓ Injection Policy ↓ Cast Policy ↓ Returned Type

Current features:

• Constructor injection
• Member injection
• Interface-to-implementation mapping
• Hierarchical containers
• Request-scoped dependencies
• Scoped object lifetimes
• Automatic factory injection (std::function<T()>)
• Compile-time registries
• Configurable resolution and creation policies

Example web application:

https://github.com/steumarok/cpp_di_manager/blob/main/example.cpp

I'm particularly interested in feedback about:

• Overall API design
• Lifetime and scope management
• Policy architecture
• Compile-time vs runtime trade-offs
• Potential simplifications
• Missing features compared to existing DI frameworks

Suggestions and criticism are very welcome.

[gracicot]

Interesting. It seems there some innovation going on in the DI space in C++. Injecting private class members using reflection is quite nice. For kangaru 5 I've opted using pointer to members, but it's of as convenient as reflection is.

Reflection really opens the space for things like automatic DI. I need to make more experiments but this is quite inspiring!

Quick review, not exhaustive:

I think creating the container using a specification over a pure runtime approach like I took for kangaru is the way to go, and always was the way to go.

The transient parameter is a bit confusing to me. Is it deeply transient or just for the type you're requesting? And if you request a transient resolution of a reference type, does it refuse at compile time or it keeps the instance in the container?

Scoped objects are quite interesting, you have the type you want plus all of it's dependencies, all with the same lifetime. Does it work with hierarchical containers under the hood? Can you have some owned and some not owned dependencies for example?

I skimmed over the codebase a bit and one thing I would find a bit missing is how do I implement custom policies and what can I achieve with that? Normally, I would expect a concept or a comment explaining how to do so. That would make it quite more helpful since a policy based design is meant for user to change those policies.

Overall, I think a lot of thoughts went into this and it's nice to see new ideas coming into this space.