Discussion :

[TocTocKiéLà?]

Bonjour,
dans un fichier j'ai quelque part :

Code :

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

1
2
3
4
5
6
7
8
9
class toto
{
 ...
void blagueur()
   {
    ...
    }
 ...
};

plus loin j'ai une autre classe titi, qui appelle blagueur da la classe toto, et là j'ai deux versions, la première :

Code :

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

1
2
TOTO test;
test.blagueur();

et la seconde :

Code :

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

1
2
TOTO *test = new TOTO();
test->blagueur();

quel est la différence entre ces deux écritures ?

[koala01]

Salut,

Au final, il n'y a pour ainsi dire pas de différence entre les deux... Tu appellera chaque fois la méthode blagueur.

Par contre, pour y arriver la différence tient dans le fait que dans le premier cas, tu travaille avec une instance de type TOTO et que dans le second, tu travaille avec un pointeur sur une instance de type TOTO.

Dans le premier cas, la mémoire nécessaire à la variable test sera d'office libérée quand tu quittera la portée dans laquelle test a été déclarée - parce qu'il s'agit d'une variable déclarée sur la pile, ou, si tu préfères, dont la mémoire a été allouée statiquement - et dans le second, tu décide de prendre le contrôle du moment où la mémoire allouée à la variable - qui a été allouée sur le tas, ou, si tu préfères, qui a été allouée dynamiquement - sera libérée (avec l'utilisation de delete). La libération de la mémoire peut donc très bien se faire en dehors de la portée dans laquelle la variable a été déclarée

[TocTocKiéLà?]

merci pour ta réponse, et elle répond d'elle même à la question que j'allais ajouter à ce topic, devrais-je utiliser un delete avec la méthode 1 - la réponse est donc non.

edit:: je vais quand même ajouter une question :
Si j'ai deux classes TOTO et titi, et que titi utilise TOTO tout au long que le programme tourne, devrais-je plutôt que d'utiliser une des deux méthodes çi-dessus faire hériter titi de TOTO ?
quel est l'impact sur la mémoire dans chacun de ces groupes (1er groupe, utiliser une des méthodes du topic 1, 2ème l'héritage) de cas ?

edit2::Autrement dit : est-ce que toutes les objets que je créer avec new et que je détruis avec delete juste avant la fermeture du programme, devraient-ils pas plutôt être héritées ?

[koala01]

Si ta classe TITI est un TOTO "amélioré", tu peux faire hériter TITI de TOTO...

Si, par contre, TITI dispose d'un TOTO, et a fortiori s'il en dispose de plusieurs, alors il faudra donner un membre de type TOTO à ton TITI.

Pour te permettre de comprendre, prenons l'exemple d'un point, d'un cercle, d'un rectangle et d'un triangle.

Un point, ce n'est que deux (ou trois) coordonnées

Code :

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

1
2
3
4
5
6
7
8
9
10
 
class point
{
    public:
        point(float x=0, float y=0)x(x),y(y){}
        ~point(){}
    private:
        float x;
        float y;
};

Alors que cercle, rectangle et triangle sont tous les trois des formes "particulières"... Dont on ne peut en aucun cas dire que ce sont des points (on peut dire qu'elles sont composées de points, par contre )


"Forme" sera donc une classe de base, qui va fournir une interface qui permettra de travailler indifféremment avec Cercle, Triangle et Rectangle qui en héritent:

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
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
 
class Forme
{
    public:
        Forme(){}
        virtual ~Forme(){}
        virtual void Tracer()=0;
};
/* Un Cercle est une Forme, il nous faut un point qui sert de centre
 * et son rayon
 */
 
class Cercle
{
    public:
        Cercle(const Point& centre, float rayon):
              Forme(),centre(centre),rayon(rayon)
        {
        }
        virtual ~Cercle()
        {
        }
        /* on redéfini Tracer pour le type Cercle */
        virtual void Tracer();
        /* et on fournit certaines fonctions utiles pour le cercle */
        /* ...*/
    private:
        /* centre devient un membre de type Point pour Cercle */
        Point centre;
        float rayon;
};
/* Un rectangle est une Forme...
 * Pour pouvoir le tracer, on a besoin d'un point (dont on va décider que
 * c'est le coin supérieur gauche, par exemple), 
 * d'une hauteur et d'une largeur
 */
class Rectangle:public Forme
{
    public:
        Rectangle(Point& coin, float haut=1.0, float larg=1.0):
                 Forme(), coin(coin),haut(haut),larg(larg)
        {
        }
        virtual ~Rectangle(){}
        /* on redéfini la fonction Tracer  pour le type Rectangle*/
        virtual void Tracer();
        /* et on fournit quelques autres fonctions utiles */
        /*...*/
    private:
        /* Pour le membre qui sert de coin, on utilise un variable de type
         * Point
        */
       Point coin;
       float haut;
       float larg; 
};
/* Enfin, pour un Triangle (quelconque) on va utiliser trois Points qui
 * serviront de limites des trois côtés... 
 * Le triangle, c'est aussi une forme :D
 */
class Triangle: public Forme
{
    public:
        Triangle(const Point& a, const Point& b, const Point& c):Forme(),
                a(a),b(b),c(c)
        {}
        virtual ~Triangle(){}
        /* on redéfini la fonction Tracer pour le triangle */
        virtual void Tracer();
        /* et on fournit quelques fonctions utiles pour le Triangle */
        /* ...*/
    private:
        /* on utilise trois variables de type Point comme membre afin
         * de pouvoir travailler sur un Triangle 
         */
        Point a;
        Point b;
        Point c;
};

Comme le point (et les autres données qui vont bien) font partie intégrante des formes qu'elles composent, la mémoire nécessaire pour représenter un point est allouée lors de la création de la forme, et est libérée au moment où la forme est détruite... que la forme soit créée sur le tas, ou sur la pile

[TocTocKiéLà?]

ok je pense avoir saisi ton exemple, de manière générale il s'agit donc de créer des objets outils "interactifs" qui renvoient quelque chose; d'utiliser les objets ainsi créés dans une colonne vertébrale d'objets qui s'héritent. Bien entendu en excluant pas le fait qu'à l'intérieur même d'un "outil" il y est de manière "local" (si je peux dire) une hiérarchie entre des classes. Bon, si je pose ces questions c'est parce que j'ai appris par moi même le C++ et que je me suis, il y a deux mois de ça, rendu compte que je n'utilise pas pleinnement les caractéristique du C++, ayant entamé un programme qui commence à être trop gros, j'ai donc un réel besoin de bien le structurer (pour faire court : un petit défaut de structure n'est pas trop important, mais la somme des petits défauts elle prend de l'importance). J'ai entre autre découvert un réel intérêt d'employer les fichiers hpp. Mais j'en étais récement venus à me demander si il n'était pas préférable d'écrire toutes les classes indépendament les unes des autres et de créer ensuite une super-classe (si je peux dire) qui hérite de la totalité des autres. Le but étant d'éviter de déclarer dans une classe un objet pas encore déclaré lui-même(c'est d'ailleurs face à ce problème que les hpp m'ont apparu comme étant util, mais ils ne règle pas tout - il me faut donc travailler l'ordre des déclarations...). Face à ça j'ai toujours le soucis de la manière dont est gérée la mémoire et le CPU mon application gérant entre autre des techniques 3D comme les shaders, la HDR... gourmandes en ressources.

[koala01]

Un petit retour à la ligne par-ci par là (voir deux) ne serait pas du luxe pour la compréhension

Comme tu introduis pas mal de choses sans réel point commun dans la conversation, je te livre "en vrac" les quelques réflexions que ton intervention m'inspire

Il me semble que tu as fait un peu vite l'impasse sur certains principes de base, et je ne peux que te conseiller de les revoir... Je parle, entre autre, de tout ce qui a trait au pointeurs, à l'allocation dynamique de la mémoire, à l'héritage et aux constructeurs

Tu mets par contre en évidence un des principaux problèmes rencontré par l'ensemble des programmeurs, même si c'est un écueil que les plus chevronnés arrivent à éviter...

Il faut bien te rendre compte que la programmation ce n'est pas uniquement le fait de "vomir" des lignes de code "au petit bonheur la chance", parce que l'on a remarqué que "telle ou telle chose pourrait s'avérer utile"...

A vrai dire, cette manière d'agir finira tôt ou tard par t'envoyer "dans le mur", et la douleur que tu en ressentira sera proportionnelle (exponentielle ) au temps qui se sera écoulée entre le début de ton projet le moment où tu finira dans le mur:

Si cela arrive après avoir écrit 50 lignes de code, cela passera (difficilement, mais cela passera)... Mais si cela arrive après avoir écrit 50.000 lignes

La bonne optique consiste à commencer par réfléchir sereinement aux besoins de l'application, en prenant en compte le fait que, quoi qu'il arrive, les besoins évolueront au fil du temps, et donc, à prendre dés le départ des précautions afin de permettre de ne pas *trop* se "casser la tête" lorsque cela arrive...

Pour information, le fait de parler de fichiers *.hpp ne veut strictement rien dire: l'extension n'étant qu'une convention, et n'étant qu'une des extensions habituellement utilisée... On préférera parler de fichier d'en-tête

Le système est suffisamment souple pour te permettre de travailler à peu près comme tu l'entend:

Tu peux, tout aussi bien, décider de regrouper la déclaration de plusieurs classes très proches (dépendantes l'une de l'autre ) dans un fichier d'en-tête, et de placer l'implémentation dans des fichiers séparés, comme tu peux décider de séparer par classe toutes les déclarations et les implémentations... Rien ne t'empêche d'ailleurs de séparer les déclarations mais de regrouper les implémentations

Dans certains cas, il faudra sans doute aussi penser aux déclarations anticipées

Essaye, autant que possible, d'utiliser les termes les plus adéquats par rapport à ce que tu veux exprimer... Le terme "déclaration" est un terme par trop générique qui peut regrouper plusieurs choses (après quelque recherche, j'ai retrouvé =>Cette intervention<= de ma part qui explique les différences )

Réfléchis peut être aussi un peu à la citation qui se trouve dans ma signature

L'héritage est un concept vraiment trop important et complexe pour être débattu de manière générique dans cette conversation et mériterait volontiers un thread à lui tout seul...

Il faut cependant savoir que le C++ est l'un des rares langages à permettre l'héritage multiple, et que l'on trouve malgré tout certains RAD ou certains EDI qui nous l'interdisent

Tout l'art d'une bonne conception va résider dans la bonne utilisation de l'héritage, mais une vue d'ensemble générale est généralement nécessaire pour se faire une idée de la meilleure solution à mettre en oeuvre

Enfin, les problèmes liés à l'utilisation des ressources et des technologies méritent eux aussi la création de threads spécifiques... Encore une fois, ce n'est que sur base d'une idée clairement identifiée que l'on pourra envisager de t'aider