Pourquoi #include <string> empêche-t-il une erreur de débordement de pile ici?

Voici mon exemple de code:

#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 je commente, #include <string>je n'obtiens aucune erreur de compilation, je suppose que c'est en quelque sorte inclus #include <iostream>. Si je "clique avec le bouton droit -> Aller à la définition" dans Microsoft VS, ils pointent tous les deux vers la même ligne dans le xstringfichier:

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

Mais lorsque j'exécute mon programme, j'obtiens une erreur d'exception:

0x77846B6E (ntdll.dll) dans OperatorString.exe: 0xC00000FD: débordement de pile (paramètre: 0x00000001, 0x01202FC4)

Une idée de la raison pour laquelle j'obtiens une erreur d'exécution lors de la mise en commentaire #include <string>? J'utilise VS 2013 Express.

En effet, comportement très intéressant.

Toute idée de la raison pour laquelle j'obtiens une erreur d'exécution en commentant #include <string>

Avec le compilateur MS VC ++, l'erreur se produit car si vous ne le faites pas, #include <string>vous n'aurez pas operator<<défini pour std::string.

Lorsque le compilateur essaie de compiler, ausgabe << f.getName();il recherche un operator<<fichier défini pour std::string. Puisqu'il n'a pas été défini, le compilateur recherche des alternatives. Il y a un operator<<défini pour MyClasset le compilateur essaie de l' utiliser, et de l' utiliser , il doit convertir std::stringà MyClassc'est exactement ce qui se passe parce que MyClassa un constructeur non explicite! Ainsi, le compilateur finit par créer une nouvelle instance de votre MyClasset essaie de la diffuser à nouveau dans votre flux de sortie. Cela se traduit par une récursion sans fin:

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

Pour éviter l'erreur, vous devez vous #include <string>assurer qu'il existe un operator<<fichier pour std::string. Vous devez également rendre votre MyClassconstructeur explicite pour éviter ce type de conversion inattendue. Règle de sagesse: rendre les constructeurs explicites s'ils ne prennent qu'un seul argument pour éviter la conversion implicite:

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

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

Cela ressemble à operator<<for std::stringest défini uniquement lorsque <string>est inclus (avec le compilateur MS) et pour cette raison, tout se compile, mais vous obtenez un comportement quelque peu inattendu car il operator<<est appelé récursivement pour MyClassau lieu d'appeler operator<<pour std::string.

Cela signifie-t-il que through #include <iostream>string n'est inclus qu'en partie?

Non, la chaîne est entièrement incluse, sinon vous ne pourrez pas l'utiliser.

Le problème est que votre code effectue une récursion infinie. L'opérateur de streaming pour std::string( std::ostream& operator<<(std::ostream&, const std::string&)) est déclaré dans le <string>fichier d' en- tête, bien qu'il soit std::stringlui-même déclaré dans un autre fichier d'en-tête (inclus à la fois par <iostream>et <string>).

Lorsque vous n'incluez pas, <string>le compilateur essaie de trouver un moyen de compiler ausgabe << f.getName();.

Il arrive que vous ayez défini à la fois un opérateur de streaming pour MyClasset un constructeur qui admet a std::string, de sorte que le compilateur l'utilise (via une construction implicite ), créant un appel récursif.

Si vous déclarez explicitvotre constructeur ( explicit MyClass(const std::string& s)), votre code ne se compilera plus, car il n'y a aucun moyen d'appeler l'opérateur de streaming avec std::string, et vous serez obligé d'inclure l'en- <string>tête.

ÉDITER

Mon environnement de test est VS 2010, et à partir du niveau d'avertissement 1 ( /W1), il vous avertit du problème:

avertissement C4717: 'opérateur <<': récursif sur tous les chemins de contrôle, la fonction provoquera un débordement de la pile d'exécution