Boost logo

Boost :

From: Dominique Devienne (ddevienne_at_[hidden])
Date: 2021-02-22 09:12:46


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: https://jcp.org/en/jsr/detail?id=330
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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk