Liste et classe abstraite

Version imprimable

13/01/2013, 20h59
lolaalol

Liste et classe abstraite

Bonjour Tout le monde !

J'ai une class abstraite "Probleme" et à deux enfants "Maladie" et "Blessure"

Mon probleme est que je dois faire une liste de "Probleme" mais je ne peux pas instancier une classe abstraite dans ma liste donc comment faire ma liste ?
14/01/2013, 04h01
koala01

Salut,

Tu dois créer une liste de pointeurs (de préférence intelligents) sur problème et y placer des pointeurs (de préférence intelligents) sur maladie ou sur blessure.

Soit toutefois attentif au fait que, une fois qu'il seront placés dans ta liste, tes différents problèmes seront connus comme... des problèmes.

Tu ne pourras donc plus envisager "sereinement" d'y accéder que comme s'il s'agissait de problème, sans précision.

Si tu te trouves face à une situation qui nécessite de savoir précisément si tu as affaire à une blessure ou à une maladie, il faudra, fatalement, passer par le double dispatch ;)
14/01/2013, 15h17
lolaalol

Justement, Problème est une classe virtuelle pure pour que je puisse utiliser le polymorphisme, je dois pouvoir faire sa genre
: Leproblem->QuelEstTonProbleme()

et cela me sort la blessure ou la maladie.

Qu'es que tu veux dire par double dispatch ?
14/01/2013, 15h40
koala01

Citation:

Envoyé par lolaalol

Justement, Problème est une classe virtuelle pure

Non...

Ce n'est qu'une question de termes, mais bons, ils sont importants ;)

Virtuelle pure, cela s'applique à certaines fonctions lorsqu'on ne donne strictement aucun comportement, à charge pour la classe dérivée de fournir le comportement qui va bien.

Une classe qui contient au moins une fonction virtuelle pure (qu'elles soit déclarée dans sa propre interface ou qu'elle soit héritée mais non définie depuis une de ses classes ancêtre) s'appelle une classe abstraite ;)

Problème est donc une classe abstraite parce que je présume que QuelEstLeProblème est une fonction virtuelle pure dans Problème ;)

Là, les termes sont bons ;)

Citation:

pour que je puisse utiliser le polymorphisme, je dois pouvoir faire sa genre
: Leproblem->QuelEstTonProbleme()

et cela me sort la blessure ou la maladie.

C'est très bien comme cela ;)

Citation:

Qu'es que tu veux dire par double dispatch ?

En fait, le double dispatch est une manière de travailler, basée sur le polymorphisme, qui permet de récupérer le type réel (dans le cas présent une maladie ou une blessure) au départ d'un objet passant pour être du type parent (ici un problème).

On appelle une fonction virtuelle disponible dans la classe mère et on la redéfini dans la classe enfant pour qu'elle transmette elle-même l'objet auquel elle appartient à un autre objet (ou une autre fonction).

Ainsi, la fonction qui est réellement appelée sait qu'elle travaille avec une blessure ou une maladie (selon ton exemple).

Il existe le patron de conception visiteur qui est un des exemples les plus courent de double dispatch (parmi ceux dont on entend régulièrement parler du moins ;) )

On parle de double dispatch "simplement" parce que tu appelle une fonction qui en appelle une autre et que c'est cette deuxième fonction qui sera réellement effective ;)

Citation:

Envoyé par koala01

En fait, le double dispatch est une manière de travaillée, basée sur le polymorphisme, qui permet de récupérer le type réel (dans le cas présent une maladie ou une blessure) au départ d'un objet passant pour être du type parent (ici un problème).

Heu, à le lire comme ça, j'ai l'impression qu'il y a méprise sur le double dispatching. C'est bien ça que tu entends?
Code:

1 2 3 4 5 6 7 8 9 10 11 class ClassAbstraite { public: virtual ~ClassAbstraite() ; // double dispatching par méthode (switch dans classe dérivée) virtual void doubleDispathMethod( const ClassAbstraite & other ) = 0 ; }; // double dispatching par fonction libre (switch/downcast imbriqués) void calculer( const ClassAbstraite & a, const ClassAbstraite & b ) ;
Dans ce cas là, c'est une espèce assez rare de visiteurs ("binary visitor").

Là je ne vois que du visiteur classique ou de la méthode virtuelle "classique" dans son cas et j'ai l'impression qu'il a tout simplement essayé de faire ça :
Code:

1 2 std::list< Probleme > problemes ;
Comment s'en sortir : Avec des pointeurs que tu auras la charge de détruire (la liste ne fera pas delete).
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 std::list< Probleme* > problemes ; problemes.insert( new Maladie() ); problemes.insert( new Blessure() ); /* En principe, on planque ça dans le destructeur d'un objet à soit qui gère et construit les problèmes */ for ( std::list< Probleme* >::iterator it = problemes.begin(); it != problemes.end(); ++it ){ it->afficheDiagnostique() ; } /* En principe, on planque ça dans le destructeur d'un objet à soit qui gère et construit les problèmes */ for ( std::list< Probleme* >::iterator it = problemes.begin(); it != problemes.end(); ++it ){ delete *it ; *it = NULL ; } problemes.clear();
C'est bien ce qui te bloquait?

PS :
- Il existe d'autres techniques plus propre pour ce genre de chose (boost::ptr_container, boost::variant,...)
- Je me demande si tu ne t'embrouille pas entre l'appel de méthode virtuelle (interface de la classe abstraite) et le downcast (dynamic_cast pour accéder à des spécificités de la classe dérivée non présente sur l'interface)

Citation:

Envoyé par bretus

Heu, à le lire comme ça, j'ai l'impression qu'il y a méprise sur le double dispatching. C'est bien ça que tu entends?

Code:

1
2
3
4
5
6
7
8
9
10
11
 
class ClassAbstraite {
public:
        virtual ~ClassAbstraite() ;
 
        // double dispatching par méthode (switch dans classe dérivée)
	virtual void doubleDispathMethod( const ClassAbstraite & other ) = 0 ;
};
 
// double dispatching par fonction libre (switch/downcast imbriqués)
void calculer( const ClassAbstraite & a, const ClassAbstraite & b ) ;

Non, tu n'as pas compris ce que j'expliquais...

J'ai dit que tu appelais depuis le ton objet passant pour être du type de base une fonction virtuelle de cet objet et que la redéfinition de cette fonction appelait une autre fonction en transmettant le type réel de l'objet.

C'est à dire

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
/* une fonction qui sait travailler sur une blessure */
void foo(Blessure const & b)
{
    /* ... */
}
/* et une qui sait travailler sur une maladie 
 * (ca pourrait etre un nom de fonction différent)
 */
void foo(Maladie const & m)
{
    /* ... */
}
class Probleme
{
    public:
        /* une fonction qui peut etre appelée depuis "n'importe quel problème"
         */
       virtual void do() /*const */ = 0;
};
class Maladie : public Probleme
{
    public:
        /* spécialisée pour une maladie la fonction ressemble à */
        virtual void do() /*const */{ foo(*this); }
};
 
class Blessure : public Probleme
{
    public:
        /* spécialisée pour une blessure, la fonction ressemble à */
        virtual void do() /* const */{ foo(*this); }
};
int main()
{
    /* que ce soit une maladie */
    Problem * ptrM = new Maladie;
    /* ou une blessure */
    Problem * ptrB = new Blessure;
    /* on peut appeler do pour les deux, et chaque implémentation
     * profite du double dispatch (deux appels de fonctions qui font qu'on
     * a récupéré le type réel de l'objet sur lequel on a appelé la première)
     */
    ptrM->do();
    ptrB->do();
    /* ... */
    delete ptrM;
    delete ptrB;
    return 0; 
}

Voilà ce qu'est le double dispatch ;)

Maintenant, si, au lieu d'avoir deux fonctions libres, il s'agissait de deux surcharge d'une même fonction membre, nous aurions affaire au patron de conception "visiteur" ;)

16/01/2013, 01h58
bretus

Ok, merci pour les précisions.
17/01/2013, 20h46
zhouyu

Salut.
Je ne vois pas l’intérêt d'utiliser le polymorphisme si au final on doit récupérer le type de l'objet ?
Pour ma part j'ai généralement une méthode commune qui est adapté en fonction de la classe enfant et qu'on appellera par la suite.
C'est pour moi la force d'utiliser le polymorphisme, peu importe la classe qu'on passe le traitement est adapté.
18/01/2013, 07h18
koala01

Citation:

Envoyé par zhouyu

Salut.
Je ne vois pas l’intérêt d'utiliser le polymorphisme si au final on doit récupérer le type de l'objet ?
Pour ma part j'ai généralement une méthode commune qui est adapté en fonction de la classe enfant et qu'on appellera par la suite.
C'est pour moi la force d'utiliser le polymorphisme, peu importe la classe qu'on passe le traitement est adapté.

Il y a des cas où tu n'as simplement pas le choix... :

Le polymorphisme te permet de travailler avec "n'importe quel type d'objet dérivé" comme s'il "s'agissait d'objet du type de base".

Tu peux donc, grâce à l'héritage et au polymorphisme, travailler avec des vélos, des voitures, des bateau et des avions mélangés dans une même collection de (pointeur sur) véhicules, mais, tu ne les connais que comme étant... des véhicules.

C'est très bien, mais jusqu'à un certain point seulement, dans le sens où il y aura fatalement un moment où, même si tu pars du principe qu'il s'agit d'un véhicule, tu devras prendre en compte le fait qu'il s'agit d'un type spécifique de véhicule pour certains services qu'ils doivent rendre.

Il faut donc régulièrement que tu sois en mesure de savoir si tu travailles avec des patins à roulettes ou avec des avions, alors que tu connait l'un et l'autre comme étant des véhicules.

Le seul moyen d'y arriver passe par... le double dispatch ;)
19/01/2013, 08h29
zhouyu

Merci pour la réponse ;)

Citation:
Envoyé par bretus
Comment s'en sortir : Avec des pointeurs que tu auras la charge de détruire (la liste ne fera pas delete).
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 std::list< Probleme* > problemes ; problemes.insert( new Maladie() ); problemes.insert( new Blessure() ); /* En principe, on planque ça dans le destructeur d'un objet à soit qui gère et construit les problèmes */ for ( std::list< Probleme* >::iterator it = problemes.begin(); it != problemes.end(); ++it ){ it->afficheDiagnostique() ; } /* En principe, on planque ça dans le destructeur d'un objet à soit qui gère et construit les problèmes */ for ( std::list< Probleme* >::iterator it = problemes.begin(); it != problemes.end(); ++it ){ delete *it ; *it = NULL ; } problemes.clear();
Es qu'on pourrait utiliser des pointeurs intelligents à la place, comme sa j'aurais pas besoin de les détruires moi même ?

Code:

list< shared_ptr<Probleme> > problemes ;

19/01/2013, 22h27
koala01

Citation:

Envoyé par lolaalol

Es qu'on pourrait utiliser des pointeurs intelligents à la place, comme sa j'aurais pas besoin de les détruires moi même ?

Code:

list< shared_ptr<Probleme> > problemes ;

oui, tout à fait, à condition bien sur que tu puisses disposer des pointeurs intelligents, soit parce que tu peux compiler en mode "C++11", soit parce que tu peux utiliser boost ;)

Cependant, je me tournerais peut etre plus volontiers vers un unique_ptr que vers un shared_ptr, mais il me manque peut-être des informations pour décider en connaissance de cause ;)
19/01/2013, 22h32
lolaalol

Citation:

Envoyé par koala01

oui, tout à fait, à condition bien sur que tu puisses disposer des pointeurs intelligents, soit parce que tu peux compiler en mode "C++11", soit parce que tu peux utiliser boost ;)

Cependant, je me tournerais peut etre plus volontiers vers un unique_ptr que vers un shared_ptr, mais il me manque peut-être des informations pour décider en connaissance de cause ;)

Merci pour votre aide.

Voici un lien vers un "article" (sur le site d'un de mes anciens professeurs), a propos des pointeurs intelligents. http://h-deb.clg.qc.ca/Sujets/AuSeco...elligents.html
19/01/2013, 23h25
koala01
Citation:

Envoyé par lolaalol

Merci pour votre aide.

Voici un lien vers un "article" (sur le site d'un de mes anciens professeurs), a propos des pointeurs intelligents. http://h-deb.clg.qc.ca/Sujets/AuSeco...elligents.html

Cet article est particulièrement instructif, et correspond, de manière générale, à ce que l'on essaye d'inculquer sur le forum.

Cependant, j'ai l'impression que cet article fait la part un peu trop belle à shared_ptr et à auto_ptr à mon gout.

En effet, ce n'est pas pour rien que auto_ptr a été déprécié en C++11, car il n'est vraiment pas en odeur de sainteté (une recherche sur le forum te donnera surement les raisons de ce fait :D) et shared_ptr n'est intéressant que lorsque tu as effectivement besoin de pointeurs partagés.

C'est pour cela que je te conseille, si tu n'a pas la possibilité de profiter des nouvelles fonctionnalités apportées par C++11, de t'intéresser un d'un peu plus près à boost et aux smart pointers que cette bibliothèque propose et, si tu peux disposer des fonctionnalités apportées par C++11 de t'interroger sur l'éventualité d'utiliser des unique_ptr par exemple.

Mais comme un conseil seul ne vaut rien, je vais me fendre de quelques raisons pour le justifier à tes yeux ;)

Si je te conseille fortement de t'orienter vers les pointeurs intelligents de boost si tu ne disposes pas des fonctionnalités de C++11, c'est parce que:
- boost est un ensemble de bibliothèques dont une bonne partie préfigure ce qui a été inclus dans C++11 ou qui a de bonne chances d'être inclus dans les normes suivantes
- boost est un ensemble de bibliothèques très largement reconnues et fortement utilisées, ce qui te garanti une très bonne stabilité à l'utilisation
Si j'insiste sur le fait que tu devrais également envisager l'utilisation de unique_ptr si tu disposes de la possibilité de recourir aux fonctionnalités de C++11, c'est essentiellement pour t'inciter à réfléchir "en profondeur" à la question "qui est responsable des pointeurs" et surtout à la question de savoir "comment seront utilisés tes pointeur".

Je ne dis pas que le choix d'un shared_ptr est mauvais en soi, je dis "simplement" que la réflexion pourrait t'amener à envisager une solution éventuellement meilleure.

Je ne serais pas étonné outre mesure qu'un unique_ptr puisse trouver grâce à tes yeux même si je n'ai, il faut bien l'avouer, qu'une connaissance vraiment partielle de ton projet ;)

Ce qui importe dans tout cela, c'est que tu ne te jettes pas sur la première solution qui se présente, mais que tu fasses un choix en connaissance de cause car le choix que tu t'apprêtes à faire est, clairement, de nature à avoir des répercussions importantes sur toute la suite de ton projet.

Alors, peut etre que la réflexion te mènera effectivement à la conclusion que tu as bel et bien besoin d'un shared_ptr, et ce sera tant mieux pour toi ;)

Mais il serait dommage de se refuser cinq minutes de réflexion pour se rendre compte, plus tard, avec l'évolution des besoin et donc l'augmentation de la complexité de ton projet, que tu aurais sans doute eu avantage à utiliser un unique_ptr (ou n'importe quel pointeur intelligent dont tu aurais pu disposer) ;)

Il m'est impossible de faire cela :
EDIT : ceci était une erreur du à ma méthod virtuelle que javais définit comme étant constante ...

Code:

1
2
liste<unique_ptr<Probleme*>> ListeDeProbleme;
ListeDeProbleme.InsererAlaFin(new Maladie(mes params...)); <- error : objet de type classe abstraite "Maladie" non autorisé

Autre truc que je ne comprend pas vraiment :

Code:

1
2
3
4
list<Probleme*> ListeDeProbleme;
ListeDeProbleme.InsererAlaFin(new Maladie(mes params...)); <- pas d'erreur
liste<unique_ptr<Probleme*>> ListeDeProbleme;
ListeDeProbleme.InsererAlaFin(new Maladie(mes params...)); <- erreur de constructeur : aucun constructeur pour la conversion de Maladie * en unique_ptr

Citation:
Envoyé par lolaalol
Il m'est impossible de faire cela :
EDIT : ceci était une erreur du à ma méthod virtuelle que javais définit comme étant constante ...
Code:

1 2 liste<unique_ptr<Probleme*>> ListeDeProbleme; ListeDeProbleme.InsererAlaFin(new Maladie(mes params...)); <- error : objet de type classe abstraite "Maladie" non autorisé
S'il te dit que Maladie est une classe abstraite, c'est très certainement parce qu'il reste une fonction virtuelle pure pour laquelle tu n'as pas fournit d'implémentation dans maladie...

Ton compilateur devrait d'ailleurs t'indiquer un peu plus loin la fonction qui est encore virtuelle pure ;)

Ceci dit, je suis étonné des noms "liste" et de "InsérerAlaFin"...tu devrais regarder plutôt soit du coté de std::list soit du coté de std::vector ;)
Citation:
Autre truc que je ne comprend pas vraiment :
Code:

1 2 3 4 list<Probleme*> ListeDeProbleme; ListeDeProbleme.InsererAlaFin(new Maladie(mes params...)); <- pas d'erreur liste<unique_ptr<Probleme*>> ListeDeProbleme; ListeDeProbleme.InsererAlaFin(new Maladie(mes params...)); <- erreur de constructeur : aucun constructeur pour la conversion de Maladie * en unique_ptr
Et pour cause, dans le deuxième cas, tu essayes d'insérer un pointeur de type problème alors que tu devrais insérer un objet de type unique_ptr<Probleme>...

L'instruction qu'il te faut est plutôt proche de
Code:

1 2 std::list<std::unique_ptr<Probleme>> listeDeProblemes; listeDeProblemes.push_back(std::unique_ptr<Probleme>(new Maladie(/*argiuments */ ) ));

21/01/2013, 00h30
lolaalol

Citation:

Envoyé par koala01

Ceci dit, je suis étonné des noms "liste" et de "InsérerAlaFin"...tu devrais regarder plutôt soit du coté de std::list soit du coté de std::vector ;)

C'est ma propre class liste et quand j'ai fais cela mon professeur ne voulais pas de nom en anglais ^^. je me suis tourné vers la list STL pour avoir moin de problème.

Comment je dois faire pour supprimer manuellement mes unique_ptr, car dans mon programme à chaque fois que je reviens au menu principale je dois supprimer mes listes. Es qu'il faut supprimer les elements de la liste avant les pointeurs ou l'inverse ?

genre :
list.clear();
delete pointer;

le but des pointeurs intelligents est, justement, de le rendre responsable de la durée de vie des pointeurs, en fonction du type de pointeur intelligent utilisé

std::unique_ptr par exemple représente un pointeur qui n'est pas partagé entre différentes classes.

Lorsque l'objet auquel il appartient est détruit, ou que l'on atteint la fin de la portée dans laquelle il est déclaré, la mémoire allouée au pointeur est correctement libérée de manière automatique:
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 class MachinTruc { public: MachinTruc():ptr(new Bidule){} /* ...*/ private: std::unique_ptr<Bidule> ptr; } int main() { MachinTruc obj; std::unique_ptr<UnType> one(new UnType); if(test) { std::unique_ptr<AutreType> two(new AutreType); /* ce qui suit n'est peut etre pas très efficace du point de vue des * performances, mais */ for(int i=0;i<10:++i) { std::unique_ptr<AutreType> three(new AutreType); /* ... */ } // libération de la mémoire allouée à three ici /* ... */ }// libération de la mémoire allouée à two ici /* ... */ return 0; } // libération de la mémoire allouée à one ici // obj est détruit : libération de la mémoire allouée à objet.ptr ici
std::shared_ptr est quant à lui un pointeur intelligent qui dispose d'un comptage de référence. La mémoire qui lui est allouée est automatiquement libérée lorsque le compteur de référence revient à 0.

Enfin std::weak_ptr représente un pointeur qui peut être invalidé, par exemple, si le compteur de référence du std::shared_ptr responsable de la durée de vie de la valeur pointée atteint 0.

Lorsque tu mets un pointeur intelligent dans une collection, tu travailles avec ce pointeur intelligent exactement comme s'il s'agissait d'une valeur quelconque: en retirant un élément de la collection, tu détruit cet élément, et la mémoire allouée à la valeur pointée est libérée "si nécessaire" (comprend : automatiquement s'il s'agit d'un std::unique_ptr, en fonction du comptage de référence s'il s'agit dun std::shared_ptr)

Du moment que tu sais à comment ton pointeur sera utilisé, le pointeur intelligent s'occupera du reste pour déterminer s'il faut libérer la mémoire allouée à l'objet pointé ou non ;)

21/01/2013, 10h43
koala01

Citation:

Envoyé par lolaalol

C'est ma propre class liste et quand j'ai fais cela mon professeur ne voulais pas de nom en anglais ^^

A titre perso, je trouve que c'est un bel imbécile...

Les noms anglais sont souvent beaucoup plus simple que leur équivalent français (push_back contre insertAlaFin, y a pas photo hein :D) mais, en plus, l'informatique est, typiquement, un domaine fortement internationalisé dans lequel on mérite de se faire comprendre du plus grand nombre.

L'anglais est la lange idéal pour remplir cet objectif ;)
21/01/2013, 12h19
JolyLoic

Citation:

Envoyé par koala01

Les noms anglais sont souvent beaucoup plus simple que leur équivalent français (push_back contre insertAlaFin, y a pas photo hein :D)

Sauf que push_back est aussi anglais que pousse_queue est français, et là la différence est plus mineure... Même si elle te saute aux yeux par l'habitude que tu as de la langue française.

Maintenant, je suis d'accord que insertAlaFin n'est pas terrible, mais insèreÀLaFin est déjà plus correct, ou ajouteEnQueue.
21/01/2013, 12h31
koala01

Citation:

Envoyé par JolyLoic

Sauf que push_back est aussi anglais que pousse_queue est français, et là la différence est plus mineure... Même si elle te saute aux yeux par l'habitude que tu as de la langue française.

Maintenant, je suis d'accord que insertAlaFin n'est pas terrible, mais insèreÀLaFin est déjà plus correct, ou ajouteEnQueue.

Nous sommes bien d'accord ;)

Ce qui est dommage dans l'optique du "aucun nom en anglais", c'est surtout que cela n'habitue pas l'élève à ce qu'il rencontrera tout au long de sa carrière professionnelle, car, une fois dans la vie active, ce seront essentiellement des noms anglais :aie:
21/01/2013, 12h41
JolyLoic

J'ai déjà discuté avec quelqu'un qui avait été appelé à déboguer du code écrit en coréen, langue qu'il ne maîtrisait bien entendu pas, et dont la graphie n'est pas des plus habituelles.

On va dire que ce fut une expérience... intéressante ;)
21/01/2013, 13h25
koala01

Citation:

Envoyé par JolyLoic

J'ai déjà discuté avec quelqu'un qui avait été appelé à déboguer du code écrit en coréen, langue qu'il ne maîtrisait bien entendu pas, et dont la graphie n'est pas des plus habituelles.

On va dire que ce fut une expérience... intéressante ;)

Ca, je veux bien croire :D

Citation:
Envoyé par koala01
l

std::unique_ptr par exemple représente un pointeur qui n'est pas partagé entre différentes classes.

Lorsque l'objet auquel il appartient est détruit, ou que l'on atteint la fin de la portée dans laquelle il est déclaré, la mémoire allouée au pointeur est correctement libérée de manière automatique:
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 class MachinTruc { public: MachinTruc():ptr(new Bidule){} /* ...*/ private: std::unique_ptr<Bidule> ptr; } int main() { MachinTruc obj; std::unique_ptr<UnType> one(new UnType); if(test) { std::unique_ptr<AutreType> two(new AutreType); /* ce qui suit n'est peut etre pas très efficace du point de vue des * performances, mais */ for(int i=0;i<10:++i) { std::unique_ptr<AutreType> three(new AutreType); /* ... */ } // libération de la mémoire allouée à three ici /* ... */ }// libération de la mémoire allouée à two ici /* ... */ return 0; } // libération de la mémoire allouée à one ici // obj est détruit : libération de la mémoire allouée à objet.ptr ici
Je comprend que la mémoire alloué sera automatique libéré mais si je veux le faire moi même.

Voici mon programme comment sa marche :

Menu Principale
Consulter ProblèmePatient
On Remplie La Liste Avec Probleme patient
On revient Menu principale
On vide la Liste
Et on recommence avec un autre patient

mes listes sont en variable globale en raison de la manière que l'interface à été fait par mon professeur.

Citation:

Envoyé par koala01

Nous sommes bien d'accord ;)

Ce qui est dommage dans l'optique du "aucun nom en anglais", c'est surtout que cela n'habitue pas l'élève à ce qu'il rencontrera tout au long de sa carrière professionnelle, car, une fois dans la vie active, ce seront essentiellement des noms anglais :aie:

Je n'ai aucun problème avec l'anglais où le français donc cela ne dérenge pas trop. Si le code est en allemand ou en chinois à ben là je vais rien comprendre ^^

21/01/2013, 17h08
koala01

Citation:

Envoyé par lolaalol

Je comprend que la mémoire alloué sera automatique libéré mais si je veux le faire moi même.

Voici mon programme comment sa marche :

Menu Principale
Consulter ProblèmePatient
On Remplie La Liste Avec Probleme patient
On revient Menu principale
On vide la Liste
Et on recommence avec un autre patient

Ce n'est pas un problème, tu peux très bien mettre une liste de unique_ptr<Probleme> dans ta classe Patient, et, lorsque le patient sera détruit, la liste de ses problème le sera de manière tout à fait correcte ;)

Citation:

mes listes sont en variable globale en raison de la manière que l'interface à été fait par mon professeur.

Ca, par contre, c'est pas bien du tout :aie:

Les variables globales, c'est le mal :vomi::scarymov::fessee::furieux:

Mais, encore une fois, au moment où tu fais un clear de ta liste de unique_ptr, tu es sur que la mémoire de tous les objets utilisés par cette liste sera correctement libérée ;)

Citation:

Je n'ai aucun problème avec l'anglais où le français donc cela ne dérenge pas trop. Si le code est en allemand ou en chinois à ben là je vais rien comprendre ^^

je crois qu'on est à peu près tous dans ce cas ;)

Ce que je voulais surtout dire par là, c'est que la très grosse majorité des interfaces auxquelles tu sera confronté sera sans doute dans la langue de shakespeare...

je trouve vraiment dommage de ne pas habituer les étudiant à un état de fait, et ce d'autant plus que ce n'est pas un cours de dissertation ou de diction, mais bien un cours d'informatique (même si j'aime trouver des textes bien orthographiés quand meme :D )
21/01/2013, 17h17
koala01

En fait, ce que je verrais bien comme solution tient à peu près à ceci:
Dans la fonction main(), tu aurais une liste qui reprend les noms des patients et les informations utiles pour arriver à les récupérer (par exemple, leur identifiant dans une base de données ou ce qui permettra de définir quel fichier lire pour accéder aux données du patient)

Lorsque le toubib reçoit un patient, il commence par en charger son historique, c'est à dire que, sur base de la liste de patients dont il dispose, il va y avoir une requête qui va avoir pour résultat de créer un objet de type Patient.

Ce type patient sera, entre autres, composé d'une liste de "problèmes" (en fait, d'une liste de pointeur intelligents sur des problèmes ;))

Le toubib doit, cela semble logique, pouvoir rajouter un problème au patient qu'il est occupé à ausculter, et la destruction du patient aura, forcément, comme résultat de "sauvegarder" (quelle qu'en soit la manière) les problèmes que le toubib aura rajouté

Bien sur, il faut aussi prévoir le fait que le patient "en cours" soit un nouveau patient, et donc permettre la création d'une nouvelle fiche ;)

Mais, a priori, il n'y a strictement pas lieu d'avoir de variables globales ;)