Rebonsoir (en effet, vous verrez surement que j'ai posté un topic récemment)

Je travaille actuellement sur un projet en C++ dont le but final est de créer une simulation de colonie de fourmis. Je travaille actuellement sur la classe fourmi dont le constructeur doit posséder comme attributs les coordonnées de la fourmi 'sur la grille, le 'numéro de la fourmi, ainsi qu’un booléen sucre pour exprimer si oui ou non la fourmi transporte du sucre.
Je suis actuellement en train de définir les méthodes de la classe dans le fichier fourmi.cpp après les avoir déclarés dans le .hpp, et il y a quelques erreurs que je n’arrive pas vraiment à comprendre :

Pour la première erreur, j’ai un constructeur de Coord dans mon fichier coord.hpp, il faudrait peut-être en créer un différent, avec quels attributs ?
Pour les autres j’ai assez de mal à comprendre.

Voici quand même quelques captures de mes fichiers histoire d'avoir le contexte :

fourmi.cpp :

fourmi.hpp (l'attribut privé num avait été commenté lors de la compilation) :

mon constructeur de coordonnées dans le fichier coord.cpp :

ma classe coord dans mon fichier coord.hpp :

En vous remerciant par avance pour les potentielles indications que vous pourriez m'apporter !

Ton constructeur de fourmi n'initialise pas son attribut c ( de type Coord). Etant donné que ta classe Coord ne possède pas de constructeur par défaut, tu dois déclarer la valeur de cet attribut dès l'initialisation de liste (je te laisse cherche sur google le fonctionnement de celle-ci).

Par ailleurs écrire fourmi::num est incorrect car ce n'est pas une variable statique de fourmi (qui plus est, le fait d'avoir une fonction statique portant le même nom que l'attribut crée une ambiguïté inutile). Si vraiment tu veux souligner le fait que c'est un attribut de ta classe, tu peux écrire this->num.
Globalement je déconseille cette syntaxe, il vaut mieux s'en tenir aux conventions de nommage, par exemple utiliser le format m_num pour tous les attributs et méthodes, et s_num pour les attributs et méthodes statiques.

Ce qui donne :

fourmi::fourmi(Coord c, int num, bool sucre) :
    m_c(c),
    m_num(num),
    m_sucre(sucre)
{
}

Le 16 mai 2021 à 22:38:20 :
Ton constructeur de fourmi n'initialise pas son attribut c ( de type Coord). Etant donné que ta classe Coord ne possède pas de constructeur par défaut, tu dois déclarer la valeur de cet attribut dès l'initialisation de liste (je te laisse cherche sur google le fonctionnement de celle-ci).

Par ailleurs écrire fourmi::num est incorrect car ce n'est pas une variable statique de fourmi (qui plus est, le fait d'avoir une fonction statique portant le même nom que l'attribut crée une ambiguïté inutile). Si vraiment tu veux souligner le fait que c'est un attribut de ta classe, tu peux écrire this->num.
Globalement je déconseille cette syntaxe, il vaut mieux s'en tenir aux conventions de nommage, par exemple utiliser le format m_num pour tous les attributs et méthodes, et s_num pour les attributs et méthodes statiques.

Ce qui donne :

fourmi::fourmi(Coord c, int num, bool sucre) :
    m_c(c),
    m_num(num),
    m_sucre(sucre)
{
}

Merci beaucoup, mes différents problèmes ont été corrigés avec cette mofication. J'irai me renseigner davantage lorsque le temps ne me fera plus défaut !

Est-ce qu’il y a une raison pour que la classe Coord ne soit pas simplement
struct Coord { int lig, col; };
?

Je pense pas que cette classe soit censée s’occuper de savoir qu’elle est la taille de la grille et de gérer les erreurs comme ça. Il serait plus simple d’avoir une simple struct qu’on peut manipuler librement (y compris la faire passer en paramètre sans avoir d’erreur) et laisser le code externe s’occuper de vérifier que la taille est bonne, etc

Le 17 mai 2021 à 09:19:57 :
Est-ce qu’il y a une raison pour que la classe Coord ne soit pas simplement
struct Coord { int lig, col; };
?

Je pense pas que cette classe soit censée s’occuper de savoir qu’elle est la taille de la grille et de gérer les erreurs comme ça. Il serait plus simple d’avoir une simple struct qu’on peut manipuler librement (y compris la faire passer en paramètre sans avoir d’erreur) et laisser le code externe s’occuper de vérifier que la taille est bonne, etc

C'est probable, mais actuellement je travaille sur un projet, qui concernent plutôt les fonctionnalités de créations de classes et objets du C++, ce qui fait que la création de classes est imposée.

Le 17 mai 2021 à 10:52:47 mxbr236 a écrit :

Le 17 mai 2021 à 09:19:57 :
Est-ce qu’il y a une raison pour que la classe Coord ne soit pas simplement
struct Coord { int lig, col; };
?

Je pense pas que cette classe soit censée s’occuper de savoir qu’elle est la taille de la grille et de gérer les erreurs comme ça. Il serait plus simple d’avoir une simple struct qu’on peut manipuler librement (y compris la faire passer en paramètre sans avoir d’erreur) et laisser le code externe s’occuper de vérifier que la taille est bonne, etc

C'est probable, mais actuellement je travaille sur un projet, qui concernent plutôt les fonctionnalités de créations de classes et objets du C++, ce qui fait que la création de classes est imposée.

Ce qu'il veut dire c'est que tu pourrais faire

class Coord 
{
public:
    int lig_{0};
    int col_{0};
};