From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2021-02-22 16:30:59
On 22/02/2021 09:08, Andrzej Krzemienski via Boost wrote:
>> What I would like to see of any Boost.DependencyInjection is the exact
>> same "one ring to rule them all" in that it should be easy to integrate
>> *any* bespoke third party Dependency Injection mechanism or framework
>> into Boost.DependencyInjection such that one can *seamlessly* compose
>> library A, library B and library C in a single application, and it all
>> "just works".
> I am having difficulties with mapping the library-interop offered by
> Outcome onto the similar library-interop that would be gained from such a
> hypothetical dependency injection library. The only way I can interpret
> your words is a situation where one library creates a recipe for injecting
> parameters to my class widget and another library uses this recipe to
> actually create objects of my type
That's not exactly what I meant.
What I meant is that if library A uses DI mechanism A, can I describe to
a Boost.DependencyInjection that mechanism A, such that mechanism A maps
100% into Boost.DependencyInjection.
To put it back into terms of Allocators, how do I tell a
Boost.DependencyInjection that for all std::vector<T, X> where X meets
the Allocator Concept, std::vector<T, X> can have an instance X injected
into its construction such that one can now write:
const auto injector = di::make_injector(
... and that makes me a std::vector<int, MyAllocator<int>>.
I'm sure it's probably possible, it's just I from my best reading of the
docs, I think it's quite awkward to do right now. And I think it ought
to not be awkward in anything Boost approves.
> But did you have something like this in mind when you wrote the above
> description? And if so, what is the value added by a dedicated library, if
> one can achieve the same foal with std::function? Is the only motivation
> that in some subset of cases the library can try to deduce (hopefully
> correctly) from the number of arguments, how I wanted to initialize the
I think you have correctly identified that arguments handling appears to
be a weak point of the current proposed library. Right now it appears to
match on most argument count first, but I'm wondering how std::vector's
non-uniform placement of the allocator instance in its constructors
could be handled without typing out a mapping function for every
std::vector constructor overload which takes an allocator instance. I
guess what I'd like to tell it is "allocator instances can appear at
argument offset 2, 5, and 6 only of the constructor", or failing that, a
constexpr initialiser list of how to map constructor args. Obviously,
completely automated deduction would be best, but without Reflection it
would murder compile times.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk