Véndeme en contenedores de COI, por favor

Question

He visto varias recomendaciones de uso de contenedores IOC en código. La motivación es simple. Tome el siguiente código inyectado de dependencia:

class UnitUnderTest
{
    std::auto_ptr<Dependency> d_;
public:
    UnitUnderTest(
        std::auto_ptr<Dependency> d = std::auto_ptr<Dependency>(new ConcreteDependency)
    ) : d_(d)
    {
    }
};


TEST(UnitUnderTest, Example)
{
    std::auto_ptr<Dependency> dep(new MockDependency);
    UnitUnderTest uut(dep);
    //Test here
}

Dentro:

class UnitUnderTest
{
    std::auto_ptr<Dependency> d_;
public:
    UnitUnderTest()
    {
        d_.reset(static_cast<Dependency *>(IocContainer::Get("Dependency")));
    }
};


TEST(UnitUnderTest, Example)
{
    UnitUnderTest uut;
    //Test here
}

//Config for IOC container normally
<Dependency>ConcreteDependency</Dependency>

//Config for IOC container for testing
<Dependency>MockDependency</Dependency>

(Lo anterior es un ejemplo hipotético de C ++ por supuesto)

Si bien estoy de acuerdo en que esto simplifica la interfaz de la clase al eliminar el parámetro del constructor de dependencia, creo que la cura es peor que la enfermedad por un par de razones. Primero, y esto es grande para mí, esto hace que su programa dependa de un archivo de configuración externo. Si necesita una implementación binaria única, simplemente no puede usar este tipo de contenedores. El segundo problema es que la API ahora es débil y peor, muy escrito. La evidencia (en este ejemplo hipotético) es el argumento de cadena al contenedor del COI y el reparto en el resultado.

Entonces ... ¿hay otros beneficios de usar este tipo de contenedores o simplemente no estoy de acuerdo con los que recomiendan los contenedores?