Discussion :

[Sceener]

Bonjour,

je pose une question d'ordre organisationnel de programmes C++ , comment peut-on au mieux structurer son programme c++ surtout s'il comporte plus que 3000 lignes .


Merci à vous tous.

[loufoque]

En découpant ton programme en des "modules" plus ou moins indépendants.

[ZaaN]

decoupe les données traitées en classes ! puis rajoute les traitement des données dans les classe correcpondantes.

Met une classe par fichier.

[rikau2]

Je viens de déposer exactement le meme type de poste....

Je fais face au meme type de probleme, il faut prendre du recul et bien chercher a savoir s'il est primordiale de raccourcir son code.

Je suis personnelement à la recherche d'une modélisation plus structurée, mais comme toujours quand tu es dedans depuis le début, les lignes finissent par s'accumuler ...

Le mieux est de poster les grds principes de ton programme et de demander des idees de modélisations.

Cdt

[Sceener]

Merci pour vos réponses , si j'ai bien compris , je mets des fichiers Header pour chaque classe et je les inclus dans mon programme principale , c'est ça ?

autre question connaissez-vous un IDE , qui peut formater les programmes c++ et les rendre plus lisible ?

Merci.

[coyotte507]

codeblocks possède un plugin qui fait ça.

[Sceener]

Super

Merci Bcp .

[koala01]

Salut,

De manière générale, il y a deux grandes optiques possibles pour structurer ton programe:

• Mettre chaque classe dans un (couple de) fichier(s) séparé(s), avec l'avantage que cela permet de gagner du temps de compilation et d'avoir des fichiers plus petits permettant de s'y retrouver plus facilement, mais l'inconvéniant que tu risques de te retrouver avec 200 fichiers pour 100 classes, et qu'il peut donc devenir difficile de gérer ces 200 "petits" fichiers, ou
• regrouper les classes par "concept"/ utilisation( /arbre d'héritage) dans un (couple) de fichier(s), avec les intérets et inconvéniants inversés: moins de fichiers à gérer, mais temps de compilation plus importants et difficulté accrue de se retrouver dans le code

Selon le projet, chacune de ces optiques peut trouver grace à tes yeux, et il est meme possible que, dans certaines conditions, tu décides de grouper un peu les deux:

Une interface graphique, avec les méthodes à créer pour la gérer, présentera un intéret certain à etre codée sous la forme des deux fichier pour une classe, alors que dans d'autre cas utilisant de nombreuses mais "petites" classes - peu de méthodes - fort proches, tu préféreras peut etre les regrouper dans un seul couple de fichiers

[Sceener]

Très clair.

Merci koala01

[Shugo78]

codeblocks possède un plugin qui fait ça.

Oui, c'est un formateur de code, ça s'appele Astyle, mais ça peut s'utiliser en dehors de code::blocks, en ligne de commande par exemple

[koala01]

Excuses moi de faire remonter le sujet, mais il y a une troisième optique envisageable, qui se trouve, pour ainsi dire, à mi-chemin des deux que j'ai citées plus haut:

Rien ne t'empeche de regrouper toutes les déclarations de classes qui ont trait à un(e) meme concept/utilisation(/arbre d'héritage) dans un seul fichier d'entete, et à implémenter les différentes fonctions dans des fichiers séparés...

Cela donnerait:
Dans arbre.h

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
44
45
46
47
48
49
 
#ifndef ARBRE_H
#define ARBRE_H
class Interface
{
    public:
        Interface(Interface* parent);
        virtual ~Interface();
        virtual void AddChild(Interface*)=0;
        virtual Interface* Parent();
        base& Data()=0; /* les données pourraient etre co variantes ;) */
/* simplement parce qu'il sera plus facile pour les classes dérivées d'y
 * accéder ;) */
    protected:
        Interface* _parent;
};
class Feuille:public Interface
{
    public:
        Feuille(Interface* parent, const derivee1& data);
        virtual ~Feuille();
        virtual void AddChild(Interface* child);
        derivee1& Data();
    private:
        derivee1_data;
};
class Noeud:public Interface
{
    public:
        Noeud(Interface* parent, const derivee2& data);
        virtual ~Noeud();
        virtual void AddChild(Interface* child);
        derivee2& Data();
    private:
        derivee2 _data;
        std::vector<Interface*> _childs;
};
class Racine:public Interface
{
    public:
        Racine(Interface* parent, const derivee3& data);
        virtual ~Racine();
        virtual void AddChild(Interface* child);
        derivee3& Data();
    private:
        derivee3 _data;
        std::vector<Interface*> _childs;
};
#endif

Dans interface.cpp

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
#include "arbre.h"
/* implémente les méthodes non virtuelles pures de l'interface */
Interface::Interface(Interface* parent):_parent(parent)
{
}
Interface::~Interface()
{
    _parent=NULL;
}
Interface* Parent()
{
    return _parent;
}

dans feuille.cpp

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
 
#include "interface.h"
/* n'implémente que les fonctions propre à la classe feuille */
Feuille::Feuille(Interface* parent, const derivee1& data): Interface(parent),
         _data(data)
{
    /* on peut estimer qu'une feuille doit etre rattachée à un noeud ;) */
    assert(_parent!=NULL);
}
Feuille::~Feuille()
{
 
}
Derivee1& Data()
{
    _return _data;
}
void AddChild(Interface*)
{
    /* on peut estimer qu'une feuille doive le rester ;) */
    assert(!"Impossible d'ajouter un enfant ici");
}

Dans noeud.cpp

Code :

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

1
2
3
4
5
 
#include "interface.h"
/* n'implémente que les fonctions membres de la classe Noeud */
 
/* j'ai la flegme... je n'écrirai rien ici :P */

Dans racine.cpp

Code :

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

1
2
3
4
5
 
#include "interface.h"
/* n'implémente que les fonctions membres de la classe racine */
 
/* j'ai la flegme... je n'écrirai rien ici :P */

Nota: l'exemple n'a pas pris en compte tous les principes d'utilisation correcte des cvqualifiers

[loufoque]

Pas terrible ta modélisation d'arbre, si tu veux mon avis.
Ça expose trop de pointeurs et de choses de ce style, la gestion mémoire n'est pas claire.

[koala01]

Pas terrible ta modélisation d'arbre, si tu veux mon avis.
Ça expose trop de pointeurs et de choses de ce style, la gestion mémoire n'est pas claire.

Le but n'était nullement de fournir un arbre fonctionnel, mais de montrer un exemple de ce qui peut etre fait au niveau des fichiers...