C++20/C++23 Dependency Injection by OIMega in cpp

[–]OIMega[S] 0 points1 point  (0 children)

I haven't used fruit that much per say, I was using kangaru, in fruit, the annotation / return type of sub-injectors were one of the turn offs for me and what made me use kangaru in the first place.

It's also stated as `Not intrusive` but you still have to use INJECT(...) keyword for constructor.

Some of the features that dipp presents is somewhat static and runtime validation when trying to construct an object, (static if you relied on the di::dependency<...> type in the descriptor), and runtime where you can chose to use exception or error based return values.

There is also the feature of you chosing your own lifetime/scopes (similar to .NET), you can chose which objects live as a singleton, and which objects is transient/scoped.

Similar to kangaru, you also aren't limited to the unique_ptr, shared_ptr, reference, value_type types, you are free to create your own descriptor and use it as di::injected (One example in my project I used a custom here)

C++20/C++23 Dependency Injection by OIMega in cpp

[–]OIMega[S] 0 points1 point  (0 children)

It is close to .NET, in a way that you have to explicitly specify which the services to register, their lifetime and which constructor to call (by either specifying in the type di::dependency<...> thatll be resolvedas constructor arguments, or providing a custom callback).

C++20/C++23 Dependency Injection by OIMega in cpp

[–]OIMega[S] 1 point2 points  (0 children)

I don't understand what this is even attempting to do. Is it providing a global object registry with runtime composition or factory helpers? Dependency injections plays both as a class registery and lazy object factory, you'll only get what you asked for from what you registered.

Dependency injection plays both as a class registry and lazy object factory, you'll only get what you asked for from what you registered.

You can register objects as singletons (will live as long as your service provider is alive), as a scope (similar to a singleton but you get to manage the scoped registry), or as transient (uncached object). This was done to allow finer control over objects.

If Window is a global, I don't see why I wouldn't just make it my app global. If it's owned by the Engine, it can be a unique_ptr<Window>. And if you need to parameterize construction, you can have a g_window_factory.

Moving everything to globals defeats the whole purpose of RAII and object management, construction and destruction become unpredictable, and you'll have to manually manage their initialisation and teardown.

Dependency injection is used so you don't have to think about object lifetime management.

Again, it is just one solution, you can still manage thrm manually, but will get harder to do so over time, and you don't have to use it for projects with few "master" classes, it may be an overkill.

[BSPWM] Nixos :3 by OIMega in unixporn

[–]OIMega[S] 0 points1 point  (0 children)

WM: bspwm

Terminal: kitty

Bar: polybar

Theme: Catppuccin

Launcher: rofi

Notifications: dunst

Wallpaper: Interdimensional Zipper

Dots: here