Partage

Erreur constructeur de classe

12 juin 2018 à 5:54:38

Bonjour , mon compilateur (GNC CC) m'as indiqué une erreur que je ne comprends pas et que je n'ait pas pu trouver sur internet.

En effet lorsque dans le .cpp j'écris ça :

#include <string>
#include <iostream>
#include "Personnage.h"


using namespace std;


   Personnage::Personnage() : m_vie(100), m_mana(100),m_arme
   {

   }


 Personnage::Personnage(string nomArme,int degatsArme) : m_vie(100), m_mana(100), m_arme(nomArme,degatsArme)
   {

   }

//tout plein d'autres methodes

Le compilateur me dit "Expected '{' before 'Personnage'

Qu'as cela ne tienne j'ai donc modifié en conséquence : 

#include <string>
#include <iostream>
#include "Personnage.h"


using namespace std;


   Personnage::Personnage() : m_vie(100), m_mana(100),m_arme
   {

   } {} //ce que j'ai rajouté


 Personnage::Personnage(string nomArme,int degatsArme) : m_vie(100), m_mana(100), m_arme(nomArme,degatsArme)
   {

   }

Ca marche , mais je ne comprends pas la logique qu'il y a derrière, quelqu'un pourrait il m'expliquer ?


Vous êtes demandeur·se d'emploi ?
Sans diplôme post-bac ?

Devenez Développeur·se web junior

Je postule
Formation
courte
Financée
à 100%
12 juin 2018 à 6:25:58

En fait tu as oublié l'initializer sur m_arme.

Donc en rajoutant les accolades, tu as

Personnage::Personnage() : m_vie(100), m_mana(100), m_arme{} {}

C'est pour ça que ça compile

PS : Tu devrais prendre un autre cours, cherche sur le forum pourquoi

-
Edité par ads00 12 juin 2018 à 6:28:53

12 juin 2018 à 10:19:58

Quitte à utiliser les listes d'initialisation, autant le faire partout, ça évitera les confusions plus tard:
Personnage::Personnage() : m_vie{100}, m_mana{100},m_arme{}
{
}
De plus, la directive "using namespace" est considérée comme une mauvaise pratique.
Soit tu qualifies pleinement tes appels de fonctions, soit tu ne sélectionne que ce dont tu as besoin.
Exemples:
int main()
{
    std::cout << "Hello world." << std::endl;
    return 0;
}

int main()
{
    using std::cout;
    using std::endl;

    cout << "Hello world." << endl;
    return 0;
}

-
Edité par Deedolith 12 juin 2018 à 10:24:08

12 juin 2018 à 21:38:30

Tu peux très bien avoir besoin d'un namespace sans avoir à faire 40 using.

Le problème la c'est d'importer toute la lib dans le scope global, mais using namespace n'est pas une mauvaise pratique. Il faut juste s'en servir correctement.

-
Edité par ads00 12 juin 2018 à 21:49:43

12 juin 2018 à 21:52:52

ads00 a écrit:

Tu peux très bien avoir besoin d'un namespace sans avoir à faire 40 using.

Le problème la c'est d'importer toute la lib dans le scope global, mais using namespace n'est pas une mauvaise pratique. Il faut juste s'en servir correctement.

-
Edité par ads00 less than 30s ago


using namespace EST une mauvaise pratique
12 juin 2018 à 22:22:48

Bonne argumentation.

namespace zeta::types
{
    struct A;
    struct B;
}

void f()
{
    using namespace zeta::types;
}

La mauvaise pratique c'est using namespace std; C'est pas pareil.

13 juin 2018 à 1:49:14

D'ailleurs, même au niveau du standard il y a des namespaces fait pour être "importés":

  • std::literals et ses sous-namespace
  • std::rel_ops
13 juin 2018 à 9:48:58

ads00 a écrit:

Bonne argumentation.

namespace zeta::types
{
    struct A;
    struct B;
}

void f()
{
    using namespace zeta::types;
}

La mauvaise pratique c'est using namespace std; C'est pas pareil.

Que ce soit l'espace de nom standard ou pas, cela revient au même.

Pour être plus précis, c'est importer un espace de nom dans la portée globale qui est réprimandable.
Dans une fonction (donc en local), on assume que le programmeur sais ce qu'il fait.
Dans la portée globale, c'est une toute autre histoire, du simple fait que plusieurs collaborateurs peuvent travailler sur un même projet, et c'est la que les conflits de nom peuvent survenir.

Ton exemple est justement le mauvais exemple, tu importes un espace de nom dans la portée d'une fonction, et ce n'est pas non plus l'erreur que l'on reproche.

13 juin 2018 à 19:45:47

Importer des symboles spécifiques et tout une librairie ça revient au même ? Pourquoi s'embêter à faire un namespace pour std::chrono::literals par exemple autant importer std à chaque fois si c'est pareil.

Que ce soit local à un fichier ou à une fonction ça ne change pas grand chose, tant que ce n'est pas un header.

Je vois pas en quoi l'exemple est mauvais vu que j'ai dis que le problème n'était pas "la directive using namespace" mais les symboles qu'on importe et dans quel scope.

14 juin 2018 à 1:28:59

ads00 a écrit :

PS : Tu devrais prendre un autre cours, cherche sur le forum pourquoi

-
Edité par ads00 12 juin 2018 à 6:28:53

Quel cour me conseille tu ? Je suis anglophone la langue n'est pas une barrière



14 juin 2018 à 2:04:18

http://guillaume.belz.free.fr/doku.php?id=programmez_avec_le_langage_c ou C++ Primer 5th Edition de S. Lippmann.
14 juin 2018 à 10:28:01

ads00 a écrit:

Importer des symboles spécifiques et tout une librairie ça revient au même ? Pourquoi s'embêter à faire un namespace pour std::chrono::literals par exemple autant importer std à chaque fois si c'est pareil.

Non, c'est importer un espace de nom (quel qu'il soit) dans l'espace global qui est une mauvaise pratique. Ce n'est pas spécifique à l'espace de nom std.

ads00 a écrit:

Je vois pas en quoi l'exemple est mauvais vu que j'ai dis que le problème n'était pas "la directive using namespace" mais les symboles qu'on importe et dans quel scope.p>

Au risque de me répéter:
"Dans une fonction (donc en local), on assume que le programmeur sais ce qu'il fait."
14 juin 2018 à 12:12:25

Sur une fonction il sait ce qu'il fait mais dans le scope d'un fichier il ne sait pas ce qu'il fait ?

Enfin bon vu que les mauvaises pratiques changent à chaque messaege, je m'arrête la.

14 juin 2018 à 14:27:32

ads00 a écrit:

Sur une fonction il sait ce qu'il fait mais dans le scope d'un fichier il ne sait pas ce qu'il fait ?

Enfin bon vu que les mauvaises pratiques changent à chaque messaege, je m'arrête la.


Ca n'a jamais changé. J'ai commencé a venir ici y'a comme 8 ans et c'etait la meme histoire : pas de using global.
Et en global il peut penser savoir ce qu'il fait mais n'est jamais a l'abris des mauvaise surprises .. comme 2 type portant le meme nom dans 2 namespace différent ..

Erreur constructeur de classe

× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
  • Editeur
  • Markdown