Discussion :

[Kemanke]

Bonjour à tous,

j'ai 2 structures du type:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
 
typedef struct s_struct1 // structure de l'ensemble des lettres
    {            
          in A; 
          char B[6]; 
          char C[6]; 
}t_struct1
 
typedef struct s_struct2 // structure de l'ensemble des lettres
    {            
          t_struct1 D; //0-8
          t_struct1 E; // 9-10
          t_struct1 F; // 11-12
}t_struct2

et dans une fonction je veux initialiser les membres de la structure 2 comme cela:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
void init_struct2(t_struct2* struct2)
{
    struct2->D={1,"bd","cd"}; 
    struct2->E={2,"be","ce"}; 
    struct2->F={3,"bf","cf"}; 
}

Mais j'ai un problème à la compilation:

Syntax before '{' token

Quelqu'un aurait il une idée?

Merci
Kemanke

[Sylvain Togni]

typedef struct s_struct1 // structure de l'ensemble des lettres
{
in A;
char B[6];
char C[6];
}t_struct1;

Ceci est du C, en C++ on écrira juste

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
struct struct1 // structure de l'ensemble des lettres
{            
          in A; 
          char B[6]; 
          char C[6]; 
};

void init_struct2(t_struct2* struct2)
{
struct2->D={1,"bd","cd"};
struct2->E={2,"be","ce"};
struct2->F={3,"bf","cf"};
}

Ceci n'est pas possible, la syntaxe avec les accolades permet d'initialiser une variable de type structure, pas d'en changer la valeur après coup.

[NiamorH]

Salut, par contre ce qui devrait passer (je ne suis même pas tout à fait certain) c'est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
void init_struct2(t_struct2* struct2)
{
  t_struct1 s1 = {1,"bd","cd"};
  t_struct1 s2 = {2,"be","ce"};
  t_struct1 s3 = {3,"bf","cf"};
 
  struct2->D = s1;
  struct2->E = s2;
  struct2->F = s3;
}

Par contre c'est pas très joli.

[doccpu]

pourquoi tu fais pas des classes (constructeurs et destructeurs intégrés) ?

[nikko34]

une struct marche comme une classe ( à la visibilité par défaut des membres près ). Tu peux très bien faire un constructeur à ta struct

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
 
struct MaStruct
{
   MaStruct( const std::string & str )
   : str_( str )
   {}
 
   std::string str_;
};

[befalimpertinent]

Utilises plutôt des constructeurs dans tes struct. ça sera plu propre

[Kemanke]

Merci de vos réponses!!

Qu'est ce que cela donnerait avec mon exemple de structure en utilisant un constructeur de struct??

Merci beaucoup encore!

Kemanke

[NiamorH]

Je crois que tu devrais commencer par lire la faq c++ dispo sur le site.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
class C1
{
public:
  C1( int a, std::string b, std::string c )
  : m_a( a ), m_b( b ), m_c( c )
  {
 
  }
 
  ~C1()
  {
 
  }
private:
  C1();
 
private:
  int m_a;
  std::string m_b;
  std::string m_c;
};
 
class C2
{
public:
  C2()
  : m_d( 1, "bd", "cd" ),
    m_e( 2, "be", "ce" ),
    m_f( 3, "bf", "cf" )
  {
 
  }
 
  ~C2()
  {
 
  }
 
private:
  C1 m_d;
  C1 m_e;
  C1 m_f;
};

[doccpu]

Je crois que tu devrais commencer par lire la faq c++ dispo sur le site.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
class C1
{
public:
  C1( int a, std::string b, std::string c )
  : m_a( a ), m_b( b ), m_c( c )
  {
 
  }
 
  ~C1()
  {
 
  }
private:
  C1();
 
private:
  int m_a;
  std::string m_b;
  std::string m_c;
};
 
class C2
{
public:
  C2()
  : m_d( 1, "bd", "cd" ),
    m_e( 2, "be", "ce" ),
    m_f( 3, "bf", "cf" )
  {
 
  }
 
  ~C2()
  {
 
  }
 
private:
  C1 m_d;
  C1 m_e;
  C1 m_f;
};

Sans vouloir vexer personne, je préfère cette implémentation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
 
class C1
{
private:
  int aA;   
  std::string aB; // 'a' comme attribute tu peux mettre 'm' comme member mais on peux les confondre avec les methodes membres
  std::string aC;
public:
  C1( int A, std::string B, std::string C )
  {
      mA = A;
      mB = B;
      mC = C;
  }
 
  ~C1()
  {
 
  }
};
 
class C2
{
 
private:
  C1 aD;
  C1 aE;
  C1 aF;
 
public:
  C2()
  {
     aD( 1, "bd", "cd" );
     aE( 2, "be", "ce" );
     aF( 3, "bf", "cf" );
  }
 
  ~C2()
  {
 
  }
 
};

que l'on soit clair c'est uniquement par soucis de clarté du code. sous cette forme on vois mieux ce qui est fait et c'est plus aéré. ceci dit cela ne change rien en termes de fonctionnalité mais c'est plus agréable a lire pour une personne qui débute ou pour une personne qui reprendra le code plus tard. La maintenabilité d'un code est souvent plus importante que sa qualité technique.

[koala01]

Salut,

Déjà, je ne vois pas pourquoi déclarer un constructeur par défaut en private, si c'est pour ne quand même pas le définir

Si on conseille de définir le constructeur par défaut, c'est parce que le compilateur risque d'en créer un s'il ne trouve aucun constructeur qui puisse prendre sa place (donc s'il ne trouve, par exemple, que le constructeur par copie), et que le constructeur qu'il (le compilateur) va placer risque de ne pas convenir.

Ainsi, dans un code du genre de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
class maclass
{
    private:
        int a;
        int b;
        int c;
};

le compilateur créera lui-même:

• un constructeur par défaut (maclass::maclass() )
• un constructeur par copie (maclass::maclass(const maclass&) )
• un destructeur par défaut (non virtuel) (maclass::~maclass() )
• un opérateur d'assignation (maclass maclass::operator=(const maclass&) )

avec les problèmes bien connus, pour tout ce qui prend une référence en argument (opérateur d'assignation et constructeur par copie), que la copie s'effectue membre à membre...

L'astuce étant que ni a, ni b, ni c ne seront initialisés... parce qu'il n'existe pas de valeur d'initialisation pour les entiers (il en serait différemment si a, b et c étaient des types utilisateurs tous "défaut constructibles"(aka dont un constructeur accepte de ne prendre aucun paramètre)

Par contre, avec un code du genre de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
class class2
{
    public:
        class2(int a, int b, int c):a(a),b(b),c(c){}
    private:
        int a;
        int b;
        int c;
};

comme le compilateur rencontre un constructeur, il ne prend pas la peine de rajouter le constructeur ne prenant aucun argument, par contre, comme il ne trouve ni constructeur par copie, ni destructeur, ni opérateur d'assignation, il va les rajouter avec des comportement "par défaut"
(la preuve: une déclaration class2 obj; sera refusé, alors que class2 o=obj; (avec obj valide) fonctionnera )

S'il faut que ta classe soit "défaut constructible", c'est à toi à t'organiser pour... Soit en définissant un constructeur ne prenant pas d'argument, soit en définissant un constructeur pour lequel tous les arguments ont des valeurs par défaut... Ex:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
class defautconst
{
    public:
        defautconst(int a=0, int b=0, int c=0):a(a),b(b),c(c){}
    private:
        int a;
        int b;
        int c;
};

qui acceptera, au choix, 0, 1, 2 ou 3 arguments et qui définira les membres dont l'argument n'est pas donné à la valeur fournie par défaut

Ensuite, et sans vouloir te vexer, doccpu, il est bien plus courent de voir les membres et méthodes publiques apparaître en premier, et cela pour une raison *relativement* simple:

La seule vue que l'on a de l'extérieur de la classe, ce sont... ses membres et méthode publiques.

La première chose que l'utilisateur doit savoir d'une classe, ce sont... ses membre et méthodes publiques.

La deuxième chose que l'utilisateur doit éventuellement savoir d'une classe (s'il veut mettre un héritage en oeuvre, par exemple), ce sont... ses membres et méthode protégé(e)s

Par contre, l'utilisateur d'une classe n'a jamais besoin de savoir quoi que ce soit de ses membres privés...

Il est donc bien plus logique de mettre tout ce qui est "d'utilisation courante"... en haut plutôt qu'en bas , tout comme il est plus logique de mettre en priorité les membres et méthodes publiques, et de ne mettre les membres et méthodes protégé(e)s qu'après

En plus, tu passera vraisemblablement bien plus de temps à modifier les méthodes qu'à modifier réellement les membres (ben oui, si tu décide de remplacer un int tab[3] en std::vector<int> tab, une fois que tu as modifié la déclaration du membre, tu dois partir à la chasse de tous les endroits où il est utilisé )

A l'usage, j'ai tendance à estimer, mais ce n'est qu'un avis strictement perso, que c'est bien plus facile à maintenir que ce que tu conseille

[befalimpertinent]

que l'on soit clair c'est uniquement par soucis de clarté du code. sous cette forme on vois mieux ce qui est fait et c'est plus aéré. ceci dit cela ne change rien en termes de fonctionnalité mais c'est plus agréable a lire pour une personne qui débute ou pour une personne qui reprendra le code plus tard. La maintenabilité d'un code est souvent plus importante que sa qualité technique.

Au contraire, dans un constructeur il faut utiliser les listes d'initialisations plutôt que l'affectation pour des soucis de performance.
Pour t'en convaincre lis cette article de la FAQ
Après tu peux l'aérer comme tu veux en sautant une ligne à chaque initialisation si tu veux.
Même pour une personnne qui débute il vaut mieux connaitre tout de suite les bonnes façon de faire plutôt qu'avoir à désapprendre réapprendre.

[NiamorH]

Tu as raison, koala01, à partir du moment où l'on écrit un constructeur, le compilateur ne cherchera plus à écrire celui par défaut. mea culpa.
Pour le reste doccpu, il n'y aucun problème, je ne vexe pas lorsqu'on me reprends. La meilleure présentation dans l'écriture d'une classe reste très subjective, surtout lorsqu'on doit faire intervenir un doxygen, et je laisse tout le monde avoir son avis.
Pour la liste d'initialisation cependant, je pense que ne pas s'en servir est une erreur.

[koala01]

Pour le reste doccpu, il n'y aucun problème, je ne vexe pas lorsqu'on me reprends. La meilleure présentation dans l'écriture d'une classe reste très subjective, surtout lorsqu'on doit faire intervenir un doxygen, et je laisse tout le monde avoir son avis.

Personnellement, mais ce n'est que mon avis , j'aurais tendance à décider de laisser le code avec juste les commentaires adéquats, et à mettre la documentation doxygen dans un (ou plusieurs) fichier(s) à part, à l'instar de ce qui se fait avec les fichier *.texi pour ceux qui utilisent texinfo

Le code est souvent déjà bien assez embrouillé et difficile à appréhender sans, en plus, avoir 10, 20 ou 30 lignes de commentaires qui ne sont là que pour la génération de documentation entre les différentes fonctions/membres.

Un simple exemple: ouvre n'importe quel fichier d'en-tête de la S(T)L (ou du moins ceux fournis par Gcc)... on finit par ne plus savoir, à force d'avoir des commentaires à rallonge, ce qui fait partie de quelle classe

[doccpu]

Tu as raison, koala01, à partir du moment où l'on écrit un constructeur, le compilateur ne cherchera plus à écrire celui par défaut. mea culpa.
....
La meilleure présentation dans l'écriture d'une classe reste très subjective, surtout lorsqu'on doit faire intervenir un doxygen, et je laisse tout le monde avoir son avis.
Pour la liste d'initialisation cependant, je pense que ne pas s'en servir est une erreur.

Je sait que la liste d'initialisation est plus rapide que l'affectation mais comme je l'ai dit plus haut, il est peu fréquent d'avoir besoins de performances exceptionnelles de plus le fait d'avoir une liste d'instructions sur une ligne me parait peu approprié pour un débutant. Pour moi une liste fait partie du domaine de l'optimisation de code et on sait tous ou sa conduit : un merdier imbitable qui oblige a beaucoup commenter pour comprendre ce qui à été fait.
Ceci dit je ne remet pas en cause l'utilisation des liste pour une utilisation le nessécitant et come tu l'a dit les gout et les couleurs ....

enfn si on veux enculer les mouches on peux dire qu'une bonne pratique serais de séparer la déclaration de l'implémentation en ne mettant q'une seule classe par fichier ect ... mais bon on vas pas donner dans la drosophilie pour un vulgaire test pour débutant hein ?


cordiallement

[Sylvain Togni]

Je sait que la liste d'initialisation est plus rapide que l'affectation mais comme je l'ai dit plus haut, il est peu fréquent d'avoir besoins de performances exceptionnelles de plus le fait d'avoir une liste d'instructions sur une ligne me parait peu approprié pour un débutant. Pour moi une liste fait partie du domaine de l'optimisation de code et on sait tous ou sa conduit : un merdier imbitable qui oblige a beaucoup commenter pour comprendre ce qui à été fait.

Je dirais que c'est plutôt une question de cohérence : quand un membre n'a pas d'operateur d'affectation, on a pas le choix, il faut passer par la liste d'initialisation, c'est l'endroit dédié. Et initialiser certains membres dans la liste et d'autres dans le corps, je ne trouve pas ça lisible du tout, je préfère tout le temps utiliser la liste.

[koala01]

J'ai appris le C++ en grande partie de manière tout à fait autodidacte...

Et c'est pourtant de manière tout à fait naturelle que j'en suis venu à utiliser les liste d'initialisation...

La raison est toute simple: je codais sous BCB, et il me faisait cruellement remarquer que, dans mon "TForm", tel ou tel membre était privé, et que je ne pouvais donc pas l'initialiser directement.

Bien plus que "rendre un code plus lisible", le fait de séparer l'implémentation de la déclaration ou de travailler avec des fichiers séparés pour les différentes classes ont des buts purement matériel:

Lors d'un héritage, le compilateur cherche la première fonction virtuelle non en ligne pour créer sa VTBL, ce qui signifie qu'il rechignera sur un code du genre de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class A
{
    public:
        A(){}
        virtual ~A(){}
        virtual void DoSomething()=0;
    /*...*/
};
class B:public A
{
    public:
       B(){}
       virtual ~B(){}
       virtual void DoSomething()
       {
           /*...*/
       }
};

parce que ~B() et DoSomething sont toutes les deux virtuelles (pas le choix pour le polymophisme)... et considérées comme en ligne.

Comme il ne trouve pas de fonction virtuelle non en ligne pour créer sa VTBL, il te sortira une erreur du genre de "impossible de créer la VTBL"...

De même, le fait d'utiliser des fichiers séparés pour les différentes classes a, principalement, pour but de limiter les temps de compilation:

Si tu mets toutes tes classes dans un même fichier, le compilateur doit... toutes les gérer.

Si tu ne modifie ne serait-ce qu'une seule de ces classes, il doit quand même gérer le fichier complet.

Et pourtant, ce n'est pas parce que tu modifie Scene que Point a été modifié, ni l'inverse d'ailleurs

En séparant Scene de Point, tu permet au compilateur de se rendre compte que "Mais les fichiers correspondant à Point n'ont pas été modifiés, je ne m'occupe donc que des fichiers correspondant à Scene, et je récupère le fichier objet de Point"... et tu gagne au final énormément de temps de compilation

Il ne s'agit pas "d'enculer les mouches", il s'agit juste de gagner du temps... là où on peut en gagner sans que cela ne nuise à la lisibilité du code

[NiamorH]

Lors d'un héritage, le compilateur cherche la première fonction virtuelle non en ligne pour créer sa VTBL, ce qui signifie qu'il rechignera sur un code du genre de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class A
{
    public:
        A(){}
        virtual ~A(){}
        virtual void DoSomething()=0;
    /*...*/
};
class B:public A
{
    public:
       B(){}
       virtual ~B(){}
       virtual void DoSomething()
       {
           /*...*/
       }
};

parce que ~B() et DoSomething sont toutes les deux virtuelles (pas le choix pour le polymophisme)... et considérées comme en ligne.

Comme il ne trouve pas de fonction virtuelle non en ligne pour créer sa VTBL, il te sortira une erreur du genre de "impossible de créer la VTBL"...

J'ai jamais vu cette erreur

[koala01]

Si tu a ne serait-ce qu'une fonction virtuelle non en ligne, tu n'auras aucun problème... Mais si tu n'en a pas, c'est un problème qui apparait systématiquement