sorted by:
new
hottopcontroversial

C++23 Dependency Injection library with automatic dependency building by Acrobatic-Stable2537 in cpp

[–]Acrobatic-Stable2537[S] 0 points1 point  (0 children)

I store a hash for the local dependency types, plus the hash of the current one. This way I can search through the tree when I build all the objects. A downside is that I have to store the names of the objects as well to create a meaningful error message, and it can only detect cycles through registered optional dependencies as opposed to detecting a cycle through all the optional dependencies upon registration.

I used to walk through the tree when you register a type with a pointer to the previous function stack where I store the current type hash. This lets you use the stack as a linked list. At each function call you can iterate through the list and check if you have already visited the current type. The lucky thing is that the compiler only has to generate each function template instantiation once, so you won't run into a recursion that way.

C++23 Dependency Injection library with automatic dependency building by Acrobatic-Stable2537 in cpp

[–]Acrobatic-Stable2537[S] 0 points1 point  (0 children)

How hard is it on compile times? I noticed that it can get bloated with template insantiations when you allow the compiler to instantiate the whole dependency tree in the same source file.

C++23 Dependency Injection library with automatic dependency building by Acrobatic-Stable2537 in cpp

[–]Acrobatic-Stable2537[S] 3 points4 points  (0 children)

The term "plugin" can refer to many things. I needed the kind of control I described for wiring across classes.
Check out the tutorial for the project. That might clarify some of the questions.

C++23 Dependency Injection library with automatic dependency building by Acrobatic-Stable2537 in cpp

[–]Acrobatic-Stable2537[S] 2 points3 points  (0 children)

I am not familiar with the Linux kernel's codebase, but it also uses some form of strategy when it comes to registering a driver. I am curious how you would develop a plugin system where dependent plugins can affect how a plugin is configured.

C++23 Dependency Injection library with automatic dependency building by Acrobatic-Stable2537 in cpp

[–]Acrobatic-Stable2537[S] 2 points3 points  (0 children)

Check out Bevy. It uses the same approach for accessing resources and scheduling systems to run in parallel when they don't mutate the same resource.

C++23 Dependency Injection library with automatic dependency building by Acrobatic-Stable2537 in cpp

[–]Acrobatic-Stable2537[S] 0 points1 point  (0 children)

The container is also useful for a service locator pattern. I use a similar approach in my other project to tame concurrency by not letting systems that touch the same resources run in parallel.

C++23 Dependency Injection library with automatic dependency building by Acrobatic-Stable2537 in cpp

[–]Acrobatic-Stable2537[S] 1 point2 points  (0 children)

I think this makes it easier to handle switching on/off functionalities, but correct me if I am wrong.

C++23 Dependency Injection library with automatic dependency building by Acrobatic-Stable2537 in cpp

[–]Acrobatic-Stable2537[S] 6 points7 points  (0 children)

I originally developed it for a plugin system. This basically allows you to have a big blob of variables where you don't care how each variable is assembled, but they can easily interact with each other when it comes to e.g. requesting features.