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
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 arguments?
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. Niall