Внедрение зависимостей в C++

inject_as_object делает привязку к одной конкретной реализации, а что, если захочется иметь две разные реализации?
Также что делать, если нужно использовать разные параметры конструктора для разных клиентов?
Мне кажется более удобным и гибким решением делать inject на уровне объектов, а не классов.

Есть несколько замечаний:
1. Ну идея определять время жизни объекта в том месте где ты его инжектишь — как минимум странная. Клас по идее вообще не должно волновать — какое время жизни у объекта — главное он есть и доступен.
2.

Объект времени исполнения (Runtime). Все клиенты используют один и тот же объект, который может изменяться во время работы программы.

Очень странное поведение. Я не могу придумать ни одной идеи где подобный подход был-бы оправдан. Плюс он создает кучу проблем (на вскидку — синхронизация переменных внутри класса, обновление значений во всех созданных объектах, что делать с тем от чего зависит этот объект).
3. Инжектить в поля — это моветон. Мешает использовать ваш объект без DI фреймворка, и делает зависимости класса менне явными (плюс много черной магии)
4. Макросы — больше черной магии в коде, которую фиг поймешь, фиг отладишь и даже затрейсишь.

Вообще статическая типизация и DI дружат очень хорошо (как раз с динамической намного больше проблем). Просто в С++ не достает средств интроспекции чтобы сделать все красиво. Посмотрите например на Dagger для Java (http://square.github.io/dagger/) он мало того что работает поверх языка со статической типизацией, как еще и проверят весь граф объектов на момент компиляции.

Вызов конструктора пришлось записать в несколько непривычном (по крайней мере, для меня) виде, потому что вариант
В том числе поэтому придумали uniform initialization:
static T instance{args...};

Мне понравилось! Спасибо, было интересно.

Вот несколько вещей которые бы я поменял:
* #define inject(I, Name) я бы реализовал в виде класса. В этом случае мы получим уменьшение объема бинарного файла, за счет уменьшения количества различных struct I##Proxy объявленных в разных классах:

// Где-то вне класса
tempalte <class I>
struct IProxy: private injector<I>::Factory {
I* operator->() {
return &this->get();
}
};

Теперь пользователь сможет инжектить зависимости так:
IProxy<IWork> mWork1;

* inject_as_share я бы реализовал с использованием std::optional/boost::optional. Это позволило бы избавиться от динамической аллокации (new)

В данной реализации все модули должны быть скомпилированы с одной настройкой фабрик.
А в managed-языках доводилось использовать такую конфигурацию, когда создаётся несколько DI-контейнеров с разными политиками, и одинаковые классы могут создаваться из разных контейнеров, получая разные зависимости.

На плюсах сходу не придумывается красивый способ. Но понятно, что создание объекта должно всегда быть с участием контейнера, что-то типа

class Employee
{
public:
    Employee(IContainer& cfg) : mWork1(cfg.resolve<IWork>()), mWork2(cfg.resolve<Work2>()) { ... }
private:
    IWork* mWork1;
    Work2* mWork2;
};

int main()
{
    Container cfg;
    cfg.RegisterSingleton<IWork, Work1>();
    Employee* e = cfg.resolve<Employee>();
    // ...
}