Boost logo

Boost :

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2021-02-22 09:25:26

pon., 22 lut 2021 o 10:12 Dominique Devienne via Boost <
boost_at_[hidden]> napisał(a):

> On Sun, Feb 21, 2021 at 4:40 PM Peter Dimov via Boost <
> boost_at_[hidden]>
> wrote:
> > By the look of it, what's being submitted is already a v3, if not v4.
> It's
> > fairly obvious that (and how) the design has evolved from runtime-based
> to
> > compile-time, for instance.
> >
> My own experience with DI comes from the Java world.
> And there, from what I saw, it's all about wiring various components at
> runtime
> from configuration files, thus I'm confused about Boost.DI being
> compile-time only.
> In Java, any piece of code can be a "plugin", given the dynamic nature of
> the runtime itself.
> So lookup, instantiation, and wiring of components at runtime is easy and
> natural. You can
> assemble at runtime (often server) programs from disparate pieces, from
> completely unrelated
> libraries (possibly even implemented in different languages compiling to
> the JVM).
> DI has been part of Java since 2009:
> And has many concrete implementations: Commons-Inject, Guice, Spring,
> Dagger, etc...
> But in C++, you can't arbitrarily instantiate any class w/o jumping through
> some hoops,
> and some runtime factory mechanism, so how can it be fully compile-time?
> True DI a-la-Java needs more that Boost.DI, no? To the point where I can
> specify the logger or DB backend of my server app at runtime. Is that
> use-case
> not part of Boost.DI? Thanks, --DD

Interesting. Maybe what Boost.DI library needs is a clear formulation of
the problem that it addresses.
Of course, it should be more specific than "Provide Dependency Injection
for C++".


> _______________________________________________
> Unsubscribe & other changes:

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