mieux structurer son programme C++ ?

Version imprimable

26/06/2007, 14h02
Sceener

mieux structurer son programme C++ ?

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.
26/06/2007, 14h17
loufoque

En découpant ton programme en des "modules" plus ou moins indépendants.
26/06/2007, 14h20
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.
26/06/2007, 14h23
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
26/06/2007, 14h24
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.
26/06/2007, 14h41
coyotte507

codeblocks possède un plugin qui fait ça.
26/06/2007, 14h43
Sceener

Super :P

Merci Bcp .
27/06/2007, 23h25
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 ;)
28/06/2007, 10h49
Sceener

Très clair.:D

Merci koala01
28/06/2007, 11h05
Shugo78

Citation:

Envoyé par coyotte507

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 ;)

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:

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:

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:

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:

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:

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 ;):P

01/07/2007, 13h46
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.
01/07/2007, 13h53
koala01

Citation:

Envoyé par 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.

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...