Dlaczego #include <string> zapobiega tutaj błędowi przepełnienia stosu?

Oto mój przykładowy kod:

#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;
}

Jeśli wykomentuję, #include <string>nie otrzymam żadnego błędu kompilatora, myślę, że jest to rodzaj dołączenia #include <iostream>. Jeśli kliknę prawym przyciskiem myszy -> Idź do definicji w programie Microsoft VS, oba wskazują ten sam wiersz w xstringpliku:

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

Ale kiedy uruchamiam program, pojawia się błąd wyjątku:

0x77846B6E (ntdll.dll) w OperatorString.exe: 0xC00000FD: przepełnienie stosu (parametr: 0x00000001, 0x01202FC4)

Masz jakieś pojęcie, dlaczego podczas komentowania pojawia się błąd wykonania #include <string>? Używam VS 2013 Express.

Rzeczywiście, bardzo ciekawe zachowanie.

Każdy pomysł, dlaczego otrzymuję błąd w czasie wykonywania podczas komentowania #include <string>

W przypadku kompilatora MS VC ++ błąd występuje, ponieważ jeśli tego nie #include <string>zrobisz, nie operator<<zdefiniujesz dla std::string.

Kiedy kompilator próbuje skompilować ausgabe << f.getName();, szuka operator<<zdefiniowanego pliku std::string. Ponieważ nie zostało zdefiniowane, kompilator szuka alternatyw. Istnieje operator<<zdefiniowane for MyClassi kompilator próbuje go użyć, a aby go użyć, musi dokonać konwersji std::stringna MyClassi tak właśnie się dzieje, ponieważ MyClassma niejawny konstruktor! Tak więc kompilator kończy tworzenie nowej instancji Twojego MyClassi próbuje ponownie przesłać strumieniowo do strumienia wyjściowego. Powoduje to nieskończoną rekursję:

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

Aby uniknąć błędu, musisz #include <string>upewnić się, że operator<<zdefiniowano dla std::string. Powinieneś także MyClasswyraźnie określić konstruktor, aby uniknąć tego rodzaju nieoczekiwanej konwersji. Zasada mądrości: uczyń konstruktory jawnymi, jeśli przyjmują tylko jeden argument, aby uniknąć niejawnej konwersji:

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

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

To wygląda operator<<na std::stringdostanie zdefiniowane tylko wtedy, gdy <string>jest włączone (z kompilatora MS) iz tego powodu wszystko kompilacji, jednak można dostać nieco nieoczekiwane zachowanie jak operator<<jest uzyskiwanie nazwie rekurencyjnie dla MyClasszamiast dzwonić operator<<do std::string.

Czy to oznacza, że #include <iostream>string jest uwzględniany tylko częściowo?

Nie, ciąg jest w pełni uwzględniony, w przeciwnym razie nie byłbyś w stanie go użyć.

Problem polega na tym, że Twój kod wykonuje nieskończoną rekurencję. Operator przesyłania strumieniowego dla std::string( std::ostream& operator<<(std::ostream&, const std::string&)) jest zadeklarowany w <string>pliku nagłówkowym, chociaż std::stringsam jest zadeklarowany w innym pliku nagłówkowym (dołączonym przez oba <iostream>i <string>).

Jeśli nie <string>dołączasz kompilatora, kompilator próbuje znaleźć sposób na kompilację ausgabe << f.getName();.

Zdarza się, że zdefiniowałeś zarówno operator przesyłania strumieniowego dla, jak MyClassi konstruktor, który dopuszcza a std::string, więc kompilator używa go (poprzez niejawną konstrukcję ), tworząc wywołanie rekurencyjne.

Jeśli zadeklarujesz explicitswój konstruktor ( explicit MyClass(const std::string& s)), twój kod nie będzie już kompilowany, ponieważ nie ma możliwości wywołania operatora przesyłania strumieniowego za pomocą std::string, a będziesz zmuszony dołączyć <string>nagłówek.

EDYTOWAĆ

Moje środowisko testowe to VS 2010 i począwszy od poziomu ostrzeżenia 1 ( /W1) ostrzega Cię o problemie:

ostrzeżenie C4717: 'operator <<': rekurencja na wszystkich ścieżkach sterowania, funkcja spowoduje przepełnienie stosu w czasie wykonywania