Boost logo

Boost :

Subject: Re: [boost] Is there any interest in a dependency injection library?
From: Kris (krzysztof_at_[hidden])
Date: 2014-07-31 10:46:18

> I'm ONLY interested in it for one reason: separately compiling bindings.
> I don't care about anything else. You are 100% correct that I prefer
> compile-time to run-time. One observation: each application will usually
> have a root "app" type, but separate modules will not. So it doesn't
> make sense to return an injector with a root type there.

Great, really happy to heart that. Hmm, when composition root is applied
then only one 'app' will be created, so it means that all modules should be
merged into one configuration, preferably in the main function and 'app'
should be created.

int main() {
    auto injector = make_injector(module1(), module2(), module3(), ...);
    return injector.create<app>().run();

But yea, it totally depends on how dependency injection is applied and I
have seen
situations when objects were created out of the modules as well, so I
your case.

> I promise you that I will try and use your library soon when I find a
> round tuit and perhaps at that point, I will find your solution is
> sufficient, but in the meantime I can only suggest things based on my
> personal experience.

Thank you :)

> Is something like this already possible? The syntax is not important,
> but how would you separately compile these two modules?

I guess your example is possible to write in the current version of the
library, but I'm not sure
if I do understand it correctly. ModuleA has some configuration and might be
compiled separately, this seems to be clear, but I do not understand what is
the responsibility of ModuleB then? Why there is 'app' there? Seems like
ModuleB might be empty, because all requirements for creating 'app' might be
found in ModuleA, unless you would like app to be bound in a different

If scope in which 'app' should changed then di::deduce<app> will expand to
unique scope, because app was created on stack? Besides scope customization
there is no need to specify which classes might be constructed using the
module, because it just depends on configuration - if bindings let you
create your class then its fine.

// ModuleA.hpp
#include "boost/di.hpp"

class this;
class that;
class animal;
class frog;

class ModuleA {
    using injector = di::injector<

    injector configure() const;

// ModuleA.cpp
#include "ModuleA.hpp

ModuleA::injector ModuleA::configure() const {
    return injector();

// app.hpp
class this;

class app {
   explicit app(this*t); // requires this (bound to that)

// ModuleB.hpp
class ModuleB {
    using injector = di::injector<>;

    injector configure() const;

// ModuleB.cpp
#include "boost/di/whatever.hpp"

ModuleB::injector configure() const {
    return injector();

// main.cpp
#include "boost/di.hpp"
#include "ModuleA.hpp"
#include "ModuleB.hpp"

int main() {
   auto injector = di::make_injector(ModuleA(), ModuleB());
   return injector.create<app>().run();

Cheers, Kris

View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at