Conserver les informations sur l'état de l'objet lors de l'appel d'un constructeur surchargé à partir du constructeur par défaut

Question

Le titre de cette question est une bouchée.Fondamentalement, je crée une structure de table de hachage qui utilise des listes doublement liées au sein d'un vecteur.Tout fonctionne bien lorsque je crée l'objet à l'aide de mon constructeur surchargé, mais l'utilisation du constructeur par défaut rend l'état de l'objet génial après son retour au principal.

Mes constructeurs :

    HashTable::HashTable()
    {
            HashTable(53);
    }

    HashTable::HashTable(int tableSize)
    {
            currentSize = tableSize;
            table.resize(tableSize);
    }

Définition de points d'arrêt après la création d'un objet

    HashTable ht(size); //this works
    HashTable ht;       //this does not work

En parcourant le code, je vois qu'il appelle correctement le constructeur surchargé, mais après être revenu à main puis avoir tenté d'utiliser la table (en utilisant uniquement le constructeur par défaut), la taille du vecteur et la variable currentSize ont mal tourné.

Après avoir créé l'objet, avant de revenir au main :

currentSize = 53
table [size] = 53, [capacity] = 53, empty linked lists fill the vector

En appelant ht.hash(value) en principal, l'objet a maintenant :

currentSize = -858993460
table [size] = 0, [capacity] = 0, linked lists obviously gone.

Qu'est-ce qui ferait que le vecteur se réinitialiserait à 0 et que mon int privé currentSize deviendrait génial, d'autant plus que les chemins de code fonctionnent tous les deux HashTable(int tableSize)?

Answer 1

@dyp m'a indiqué la bonne direction.

HashTable(53); je créais un objet local temporaire - sans définir l'objet principal à la taille souhaitée de 53.

Pour appeler le constructeur surchargé sur mon objet dans main plutôt que de créer un objet temporaire, this->HashTable::HashTable(53); travaillé (dans Visual Studio) pour forcer l'appel du constructeur surchargé sur mon objet appelant.

MODIFIER:Le compilateur gcc l'interdit, et cela est généralement considéré comme une mauvaise pratique, que votre compilateur le permette ou non.

Une liste d'initialiseurs comme HashTable::HashTable() : HashTable(53) {} est considéré comme la bonne façon d’accomplir ce que j’essayais de faire.