¿Por qué #include <string> evita un error de desbordamiento de pila aquí?

Este es mi código de muestra:

#include <iostream>
#include <string>
using namespace std;

class MyClass
{
    string figName;
public:
    MyClass(const string& s)
    {
        figName = s;
    }

    const string& getName() const
    {
        return figName;
    }
};

ostream& operator<<(ostream& ausgabe, const MyClass& f)
{
    ausgabe << f.getName();
    return ausgabe;
}

int main()
{
    MyClass f1("Hello");
    cout << f1;
    return 0;
}

Si comento #include <string>, no obtengo ningún error de compilación, supongo que se incluye de alguna manera #include <iostream>. Si hago "clic derecho -> Ir a definición" en Microsoft VS, ambos apuntan a la misma línea en el xstringarchivo:

typedef basic_string<char, char_traits<char>, allocator<char> >
    string;

Pero cuando ejecuto mi programa, aparece un error de excepción:

0x77846B6E (ntdll.dll) en OperatorString.exe: 0xC00000FD: Desbordamiento de pila (Parámetro: 0x00000001, 0x01202FC4)

¿Alguna idea de por qué aparece un error de tiempo de ejecución al comentar #include <string>? Estoy usando VS 2013 Express.

De hecho, comportamiento muy interesante.

Alguna idea de por qué me aparece un error de tiempo de ejecución al comentar #include <string>

Con el compilador MS VC ++, el error ocurre porque si no lo hace, no #include <string>lo habrá operator<<definido std::string.

Cuando el compilador intenta compilar ausgabe << f.getName();busca un operator<<definido para std::string. Como no se definió, el compilador busca alternativas. Hay unoperator<< definida por MyClassy los intentos del compilador para usarlo, y para utilizarlo se tiene que convertir std::stringa MyClassy esto es exactamente lo que sucede porque MyClasstiene un constructor no explícito! Entonces, el compilador termina creando una nueva instancia de tu MyClasse intenta transmitirlo nuevamente a tu flujo de salida. Esto resulta en una recursión sin fin:

 start:
     operator<<(MyClass) -> 
         MyClass::MyClass(MyClass::getName()) -> 
             operator<<(MyClass) -> ... goto start;

Para evitar el error necesitas #include <string> asegurarse de que haya un operator<<definido para std::string. También debe hacer que su MyClassconstructor sea explícito para evitar este tipo de conversión inesperada. Regla de sabiduría: haga explícitos a los constructores si toman solo un argumento para evitar la conversión implícita:

class MyClass
{
    string figName;
public:
    explicit MyClass(const string& s) // <<-- avoid implicit conversion
    {
        figName = s;
    }

    const string& getName() const
    {
        return figName;
    }
};

Parece que operator<<para la std::stringobtiene sólo cuando se define<string> se incluye (con el compilador MS) y para que compila razón, todo, sin embargo, se obtiene un comportamiento algo inesperado ya que operator<<se llama de forma recursiva para conseguir MyClassen lugar de llamar operator<<a std::string.

¿Eso significa que a través de la #include <iostream>cadena solo se incluye parcialmente?

No, la cadena está completamente incluida, de lo contrario no podría usarla.

El problema es que su código está haciendo una recursión infinita. El operador de transmisión para std::string( std::ostream& operator<<(std::ostream&, const std::string&)) se declara en el <string>archivo de encabezado, aunque std::stringsí se declara en otro archivo de encabezado (incluido por ambos <iostream>y <string>).

Cuando no incluye <string>el compilador intenta encontrar una manera de compilar ausgabe << f.getName();.

Sucede que ha definido tanto un operador de transmisión MyClasscomo un constructor que admite a std::string, por lo que el compilador lo usa (a través de la construcción implícita ), creando una llamada recursiva.

Si declara explicitsu constructor ( explicit MyClass(const std::string& s)), su código ya no se compilará, ya que no hay forma de llamar al operador de transmisión std::stringy se verá obligado a incluir el <string>encabezado.

EDITAR

Mi entorno de prueba es VS 2010, y comenzando en el nivel de advertencia 1 ( /W1) le advierte sobre el problema:

advertencia C4717: 'operador <<': recursivo en todas las rutas de control, la función provocará un desbordamiento de la pila en tiempo de ejecución