Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1618 connectés 

  FORUM HardWare.fr
  Programmation
  C++

  pb de conception orientée objet

 
 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

pb de conception orientée objet

n°1156017
ddesbuis
Posté le 21-07-2005 à 14:16:40  profilanswer
 

voila mes classes :
 

Code :
  1. class PtBasic
  2. {
  3. public :
  4.     PtBasic();
  5.     PtBasic(double xv, double yv, double zv);
  6.     virtual ~PtBasic();
  7.    
  8.     PtBasic& PtBasic::operator = (const PtBasic& pt);
  9.    
  10.     double DistToPt   (const PtBasic& pt) const;
  11.     double DistHzToPt (const PtBasic& pt) const;
  12.     void ChangeCS (const PtBasic& O, const ROTATION::MatRot& R);
  14.     void Bary(const PtBasic& pt1, const PtBasic& pt2, const PtBasic& pt3);
  15.    
  16.     virtual std::string Nom() const;
  17.    
  18.     double X() const;
  19.     double Y() const;
  20.     double Z() const;
  21.    
  22.     virtual double Ex() const;
  23.     virtual double Ey() const;
  24.     virtual double Ez() const;
  25.    
  26.     double x,y,z;
  27. };
  29. bool operator == (const PtBasic& a, const PtBasic& b);
  30. bool operator != (const PtBasic& a, const PtBasic& b);
  32. std::ostream& operator<<(std::ostream& out, const PtBasic& pt);
  33. std::istream& operator>>(std::istream&  in, PtBasic& pt);
  36. class SetPtBasic
  37. {
  38. public :
  39.     SetPtBasic();
  40.     SetPtBasic(const SetPtBasic& setpt);
  41.     ~SetPtBasic();
  42.    
  43.     SetPtBasic& operator = (const SetPtBasic& setpt);
  44.    
  45.     Plan   PlanMoyen  (std::ostream& out) const;
  46.     double ZMoyen     (std::ostream& out) const;
  47.     double ZMoyenPond (std::ostream& out, PtBasic PtRef, double dmax) const;
  48.    
  49.     std::vector<PtBasic*> Pt;
  50. };
  53. class PtCal : public PtBasic
  54. {  
  55. public :
  56.     PtCal();
  57.     PtCal(const PtBasic& pt);
  58.     PtCal(const PtCal& pt);
  59.     virtual ~PtCal();
  60.    
  61.     PtCal& operator = (const PtCal& pt);
  62.    
  63.     virtual double Ex() const;
  64.     virtual double Ey() const;
  65.     virtual double Ez() const;
  67.     PtBasic MakeItBasic() const;
  68.    
  69.     virtual std::string Nom() const;
  70.    
  71.    std::string nom;
  72.    bool connu;
  73.     double ex, ey, ez;
  74. };
  76. bool operator == (const PtCal& a, const PtCal& b);
  77. bool operator != (const PtCal& a, const PtCal& b);
  80. class SetPtCal : public SetPtBasic
  81. {
  82. public :
  83.     SetPtCal ();
  84.     SetPtCal (const SetPtCal& setpt);
  85.     ~SetPtCal ();
  86.    
  87.     SetPtCal& operator = (const SetPtCal& setpt);
  88.  
  89.     void LoadPtCal (std::string nomfcalage);
  90.     void SavePtCal (std::string nomfcalage) const;
  91.  
  92.     void AddPtCal  (std::string nomfcalage);
  93.     void AddPtCal  (PtCal pt);
  94.  
  95.     bool  PtInc (std::string nompoint) const;
  96.     unsigned int GetPt (std::string nompoint) const;
  97.  
  98.     void PrintNXYZEXYZ (std::ostream& out) const;
  99.     void PrintNXYZ (std::ostream& out) const;
  100. };


 
j'ai donc un objet PtBasic qui ne contient que x,y,z la base
un objet PtCal qui possede en plus un nom et des ecarts types en x y et z -> ex ey et ez
 
ensuite j'ai des ensemble de PtBasic
et des ensembles de PtCal
 
je dois pouvoir realises sur les ensemble de PtCal toutes les operations possible sur les ensembles de PtBasic plus d'autres
 
le pb si je vais herite SetPtCal de SetPtBasic c'est que le std::vector<PtBasic*> Pt m'oblige à definir des fonctions virtuelle debile dans PtBasic (Ex() etc....) ces fonctions n'ont aucune raison d'etre puisque le PtBasic n'a pas de ex...
 
bref je n'arrive pas à voir comment organiser ma hierarchie pour pouvoir virer ces stupides :
 

Code :
  1. virtual std::string Nom() const;
  2.    
  3.    
  4.     virtual double Ex() const;
  5.     virtual double Ey() const;
  6.     virtual double Ez() const;


 
de l'objet PtBasic
 
et que les appele à SetPtCal::Pt->Ex() depuis les fonctions externes aux objets fonctionnent !!!
 
 
j'avais penser à ecraser  
 

Code :
  1. std::vector<PtBasic*> Pt;


 
dans SetPtCal par :
 

Code :
  1. std::vector<PtCal*> Pt;


 
mais ca n'est pas accepté parceque surement pas correct...
 
merci a ceux qui prendront le temps de m'aider
 
David

mood
Publicité
Posté le 21-07-2005 à 14:16:40  profilanswer
 

n°1156165
theshockwa​ve
I work at a firm named Koslow
Posté le 21-07-2005 à 15:45:32  profilanswer
 

ou sinon, tu peux faire des static_cast de tes PtBasic vers PtCal dans ton SetPtCal, auquel cas tu n'as plus besoin de tes méthodes virtuelles ...
 
( J'ai lu rapidement, vu que je suis au boulot, là, donc désolé si je réponds à côté :D )

n°1156229
ddesbuis
Posté le 21-07-2005 à 16:12:18  profilanswer
 

je n'avais pas penser à ca ...
 
mais comme le vector <PtBasic*> est public il faut à chaque fois qu'un utilisateur de la classe SetPtCal utilise un
par exemple pt[i]->Nom() il pense à faire d'abord un static_cast pour convertir PtBasic* en PtCal* ce qui est quand meme con pour un point sortant d'un ensemble de PtCal....

n°1156240
theshockwa​ve
I work at a firm named Koslow
Posté le 21-07-2005 à 16:14:33  profilanswer
 

bah, surcharge l'opérateur [] de ton SetPtCal pour qu'il fasse un accès à ton vecteur public et retourne le type casté :o

n°1156253
ddesbuis
Posté le 21-07-2005 à 16:18:07  profilanswer
 

c'est une idée.... effectivement.. je devrais peut être mettre :
Private :  
std::vector<PtBasic*> Pt;
 
et n'y acceder que par des fonctions ou surcharge d'operateur []
 
mais je me demande quand meme si je ne suis pas completement a cote de la plaque avec cette hierarchie de classe.... ca me semble un peu bancale mon affaire

n°1156256
Kristoph
Posté le 21-07-2005 à 16:20:13  profilanswer
 

theshockwave a écrit :

bah, surcharge l'opérateur [] de ton SetPtCal pour qu'il fasse un accès à ton vecteur public et retourne le type casté :o


 
Wow, ça a une chance de marcher ça ? :ouch:

n°1156266
theshockwa​ve
I work at a firm named Koslow
Posté le 21-07-2005 à 16:26:06  profilanswer
 

oui, enfin, ca ne retournera pas le type à proprement parler [:petrus75]
Je me suis mal exprimé, ca fera juste le lien vers le vecteur avec un cast au passage, quoi. En gros :
 

Code :
  1. class SetPtCal : public SetPtBasic
  2. {
  3. public :
  4. // ...
  5.   PtCal * operator[](size_t i) {
  6.     return static_cast<PtCal *>Pt[i];
  7.   }
  8. };

n°1156270
theshockwa​ve
I work at a firm named Koslow
Posté le 21-07-2005 à 16:26:45  profilanswer
 

Cependant, je me demande s'il ne serait pas mieux, pour ce genre de choses de préférer une agrégation à l'héritage ...

n°1156287
ddesbuis
Posté le 21-07-2005 à 16:37:54  profilanswer
 

en fait c'est surtout la relation de SetPtBasic avec SetPtCal qui me pose probleme...
 
les PtCal contenu ds SetPtCal doivent par exemple pouvoir faire l'objet d'un calcul de plan moyen defini dans SetPtBasic( car il n'est pas besoin d'être PtCal pour avoir un plan moyen le niveau de definition PtBasic suffit pour ca)
 
par contre dans le SetPtCal il y a des fonctions plus avancées ou le nom des Points (uniquement ds PtCal) joue un role...

n°1156293
Kristoph
Posté le 21-07-2005 à 16:41:43  profilanswer
 

Il y a un problème de conception ici. En supposant que SetPtBasic et SetPtCal sont des conteneurs, tu voudrais un SetPtCal qui hérite de SetPtBasic mais qui ajoute :
- des fonctionalités ( pas de problème )
- des contraintes sur les objets manipulés ( problème car pas faisable en C++ facilement )
 
Je suggère de transformer ces deux conteneurs en template et de spécialisé la version SetPtCal pour ajouter les fonctionalités qui lui manquent par exemple ( si c'est possible, il me semble que oui )

mood
Publicité
Posté le 21-07-2005 à 16:41:43  profilanswer
 

n°1156300
ddesbuis
Posté le 21-07-2005 à 16:45:07  profilanswer
 

je suis d'accord sur le fait qu'il y a un pb de conception... car je tourne en rond sur cette idée depuis un moment... et quoi que je fasse il y a tjs un pb...
 
par contre moi et les template ca fait 2 ..; je ne connait pas ce type de programmation... tu peux ma donner une piste ?

n°1156307
Kristoph
Posté le 21-07-2005 à 16:48:31  profilanswer
 

ddesbuis a écrit :

je suis d'accord sur le fait qu'il y a un pb de conception... car je tourne en rond sur cette idée depuis un moment... et quoi que je fasse il y a tjs un pb...
 
par contre moi et les template ca fait 2 ..; je ne connait pas ce type de programmation... tu peux ma donner une piste ?


Pas trop non, mes templates C++ sont un peu rouillées par manque de pratique ces derniers temps :whistle:

n°1156308
theshockwa​ve
I work at a firm named Koslow
Posté le 21-07-2005 à 16:49:41  profilanswer
 

les templates, ca sert à faire de la généricité, et si tu as deux comportement différents à traiter, utiliser des templates ne sera peut-être pas une bonne idée, non ?
 
je proposais de l'agrégation pour le problème des sets, justement.
 
Je verrais bien une interface commune aux deux sets à la limite, et SetPtCal qui "contient" (ou agrège, donc) un SetPtBasic et a donc tout contrôle dessus. Il servirait donc d'interface évoluée vers le set plus générique.

n°1156312
Kristoph
Posté le 21-07-2005 à 16:51:55  profilanswer
 

theshockwave a écrit :

les templates, ca sert à faire de la généricité, et si tu as deux comportement différents à traiter, utiliser des templates ne sera peut-être pas une bonne idée, non ?
 
je proposais de l'agrégation pour le problème des sets, justement.
 
Je verrais bien une interface commune aux deux sets à la limite, et SetPtCal qui "contient" (ou agrège, donc) un SetPtBasic et a donc tout contrôle dessus. Il servirait donc d'interface évoluée vers le set plus générique.


 
Les template ça sert à faire plein de choses et cela me semble très adapté dans ce cas car cela evite d'avoir un conteneur sous typé avec cast horrible partout.

n°1156317
ddesbuis
Posté le 21-07-2005 à 16:54:28  profilanswer
 

:pt1cable:  
 
moi j'ai rien contre mais dans ma bible C++ c'est pas expliqué l'agregation ??
 
pourrais tu brievement decrire les relations que tu mettrais en place en les classe PtBasic PtCAl SetPtBasic et SetPtCal ?
 
à mon avis PtBasic comme classe de base pour PtCal ca c'est bon  :sol:  
 
par contre je suppose que tu changerais la relation SetPtBasic et SetPtCal  :pt1cable:  
voir meme que tu creerai une autre classe intermediaire ou sous jacente non ?  :whistle:

n°1156319
theshockwa​ve
I work at a firm named Koslow
Posté le 21-07-2005 à 16:55:13  profilanswer
 

oui, j'ai été un peu réducteur, mais bon ... Pour ma part, je serais resté sur un système avec une interface dans laquelle je n'ai pas de spécialisation du vecteur et deux implémentations de l'interface : une pour le SetPtBasic et l'autre pour le SetPtCal, chacun intégrant son vecteur qui va bien et implémentant la bonne interface

n°1156333
ddesbuis
Posté le 21-07-2005 à 17:01:38  profilanswer
 

la je suis d'accord pour moi c'est l'idee de base mais ca ne marche pas !!! en tout cas de la maniere dont je le fait
 
quand dans SetPtCal en ayant un :

Code :
  1. std::vector<PtBasic*> Pt;

provenant de SetPtBasic
 
je veux acceder à
Pt[i]->Nom() il me jette a la rue...
 
d'ou ton idee des static cast et autre surcharge[]....
 
c'est peut etre la solution remarque ... en y reflechissant c'est pas si bancale que ca ....

n°1156339
theshockwa​ve
I work at a firm named Koslow
Posté le 21-07-2005 à 17:05:13  profilanswer
 

justement, non, ce n'est pas ce que tu fais ...
 
il te faudrait quelque chose de ce type :
 

Code :
  1. class ISetPt {
  2. public:
  3.   // fonctions communes sans implémentation
  4.   // pas de vecteur
  5. };
  7. class SetPtBasic : public ISetPt {
  8. private:
  9.   std::vector<PtBasic *> pt;
  10. public:
  11.   // implémentation des méthodes de l'interface
  12. };
  15. class SetPtCal : public ISetPt {
  16. private:
  17.   std::vector<PtCal *> pt;
  18. public:
  19.   // implémentation des méthodes de l'interface
  20.   // ajout de méthodes spécifiques
  21. };

n°1156343
theshockwa​ve
I work at a firm named Koslow
Posté le 21-07-2005 à 17:08:08  profilanswer
 

Si tu tiens à faire des templates, tu peux aussi faire ca :
 

Code :
  1. template <class PT>
  2. class SetPt {
  3. private:
  4.   std::vector<PT *> pt;
  5. public:
  6.   // fonctions communes
  7. };
  9. class SetPtBasic : public SetPt<PtBasic> {
  10.   // toutes les méthodes y sont déjà
  11. };
  13. class SetPtCal : public SetPt<PtCal> {
  14. public:
  15.   // ajout de méthodes spécifiques
  16. };


 
Le désavantage que tu pourras y voir, c'est que tu ne pourras plus utiliser ton SetPtCal comme s'il s'agissait d'un SetPtBasic ...
 
Edit : en fait, le problème se poserait aussi avec la méthode au-dessus à cause de la virtualité des méthodes définies dans l'interface commune :/


Message édité par theshockwave le 21-07-2005 à 17:09:55
n°1156345
Kristoph
Posté le 21-07-2005 à 17:10:00  profilanswer
 

theshockwave a écrit :

justement, non, ce n'est pas ce que tu fais ...
 
il te faudrait quelque chose de ce type :
 

Code :
  1. class ISetPt {
  2. public:
  3.   // fonctions communes sans implémentation
  4.   // pas de vecteur
  5. };
  7. class SetPtBasic : public ISetPt {
  8. private:
  9.   std::vector<PtBasic *> pt;
  10. public:
  11.   // implémentation des méthodes de l'interface
  12. };
  15. class SetPtCal : public ISetPt {
  16. private:
  17.   std::vector<PtCal *> pt;
  18. public:
  19.   // implémentation des méthodes de l'interface
  20.   // ajout de méthodes spécifiques
  21. };



Chose qui n'a aucun interet sauf si tu veux faire du polymorphisme avec les conteneurs SetPt... :) Si ce n'est pas le cas, pas la peine de s'emcombrer avec ISetPt.
 
En fait, il y a un peu de généricité ici : les deux std::vector ne sont pas compatible entre eux par heritage mais ils le sont pas généricité.

n°1156346
ddesbuis
Posté le 21-07-2005 à 17:10:06  profilanswer
 

oui mais par exemple la fonction  
 
Plan   PlanMoyen  (std::ostream& out) const;
 
elle à exactement la meme implementatation avec des PtCal ou avec des PtBasic ....
 
dans ce cas je devrais l'implementer deux fois de la meme maniere  
 
il devrait etre possible de ne l'implementer qu'une fois ...

n°1156347
ddesbuis
Posté le 21-07-2005 à 17:12:16  profilanswer
 

je parlai de la methode de theShOcKwAvE dans mon message precedant

n°1156350
theshockwa​ve
I work at a firm named Koslow
Posté le 21-07-2005 à 17:13:35  profilanswer
 

ben, il suffit, dans l'interface que j'ai mentionnée plus haut, de mettre un système pour accéder aux éléments de ton vecteur dans le type PtBasic, et c'est ok, non ?

n°1156353
ddesbuis
Posté le 21-07-2005 à 17:14:53  profilanswer
 

oui la methode avec les template me semble etre la bonne car me permettant de definir une seule fois mes fonctions PlanMoyen etc ....
 
bon maintenant il faut que je lise sur les template car je n'ai jamais utiliser ca avant ... umffff

n°1156355
theshockwa​ve
I work at a firm named Koslow
Posté le 21-07-2005 à 17:19:26  profilanswer
 

ben ... à moins que tu définisses ta fonction PlanMoyen comme template elle-aussi, ca ne collera pas, non

n°1156364
ddesbuis
Posté le 21-07-2005 à 17:28:04  profilanswer
 

Code :
  1. template <class PT>
  2.    
  3.     class SetPt {
  4.     private:
  5.       std::vector<PT *> pt;
  6.     public:
  7.       // fonctions communes
  8.     };
  9.    
  10.     class SetPtBasic : public SetPt<PtBasic> {
  11.       // toutes les méthodes y sont déjà
  12.     };
  13.    
  14.     class SetPtCal : public SetPt<PtCal> {
  15.     public:
  16.       // ajout de méthodes spécifiques
  17.     };


 
imaginons que dans SetPt je fasse :
 

Code :
  1. class SetPt {
  2.     private:
  3.       std::vector<PT *> pt;
  4.     public:
  5.       Plan   PlanMoyen  (std::ostream& out) const;
  6.     };


 
et que dans cette fonction PlanMoyen j'ai :
 

Code :
  1. Plan SetPtBasic::PlanMoyen (std::ostream& out) const
  2. {
  3.     MC::sysmc resol (Pt.size (), 3);
  4.        
  5.     for(unsigned int i=0; i<Pt.size (); i++)
  6.     {
  7.         resol.A (i, 0) = Pt[i]->X();
  8.         resol.A (i, 1) = Pt[i]->Y();
  9.         resol.A (i, 2) = 1;
  10.        
  11.         resol.L (i) = Pt[i]->Z();
  12.     }
  13.    
  14.     resol.SolveMC (std::cout);
  15.    
  16.     Plan Pl;
  17.    
  18.     Pl.a = resol.dP (0);
  19.     Pl.b = resol.dP (1);
  20.     Pl.c = -1;
  21.     Pl.d = resol.dP (2);
  22.    
  23.     return Pl; 
  24. }


 
ca ne marchera pas ? je veux dire je ne serais pas capable d'acceder au fonction de PtBasic à partir de la classe Template PT ?

n°1156372
theshockwa​ve
I work at a firm named Koslow
Posté le 21-07-2005 à 17:34:29  profilanswer
 

ah, si, désolé, je n'avais pas réalisé que PlanMoyen était une méthode de ton set ... donc ce cas, oui, ca passe ... Par contre, documente-toi un peu plus sur les templates parce que tu vas aavoir un peu de mal sans ca :D

n°1156392
ddesbuis
Posté le 21-07-2005 à 17:57:28  profilanswer
 

j'imagine que je vais me faire quelques suées grave :-)
 
bon ben d'ici quelque jour je mettrai le code qui marche en ligne .... yop yop

n°1156395
theshockwa​ve
I work at a firm named Koslow
Posté le 21-07-2005 à 18:00:42  profilanswer
 

Avant que tu ne t'arraches les cheveux : mets les définitions des méthodes templates dans le même fichier que leur déclaration, tu chercheras à comprendre ca plus tard :o

n°1156397
ddesbuis
Posté le 21-07-2005 à 18:04:13  profilanswer
 

tiens donc ... bon si tu le dis .... humf je renifle deja les plans zarb....

n°1156442
slash33
Posté le 21-07-2005 à 19:03:36  profilanswer
 

theshockwave a écrit :

Avant que tu ne t'arraches les cheveux : mets les définitions des méthodes templates dans le même fichier que leur déclaration, tu chercheras à comprendre ca plus tard :o


C'est clair la première fois ça fait bizzard!  :pt1cable:

n°1157374
ddesbuis
Posté le 22-07-2005 à 16:06:02  profilanswer
 

Code :
  1. class PtBasic
  2. {
  3. public :
  4.     PtBasic();
  5.     PtBasic(double xv, double yv, double zv);
  6.     virtual ~PtBasic();
  7.    
  8.     PtBasic& PtBasic::operator = (const PtBasic& pt);
  9.        
  10.     double X() const;
  11.     void SetX(double value);
  12.     void AddToX(double value);
  13.    
  14.     double Y() const;
  15.     void SetY(double value);
  16.     void AddToY(double value);
  17.    
  18.     double Z() const;
  19.     void SetZ(double value);
  20.     void AddToZ(double value);
  21.    
  22.     void SetXYZ(double vx, double vy, double vz);
  23.    
  24.     double DistToPt   (const PtBasic& pt) const;
  25.     double DistHzToPt (const PtBasic& pt) const;
  27.     void ChangeCS (const PtBasic& O, const ROTATION::MatRot& R);
  29.     void Bary(const PtBasic& pt1, const PtBasic& pt2, const PtBasic& pt3);
  31.    
  32. private :
  33.    double x,y,z;
  34. };
  36. bool operator == (const PtBasic& a, const PtBasic& b);
  37. bool operator != (const PtBasic& a, const PtBasic& b);
  39. std::ostream& operator<<(std::ostream& out, const PtBasic& pt);
  40. std::istream& operator>>(std::istream&  in, PtBasic& pt);
  43. class SetPtBasic
  44. {
  45. public :
  46.     SetPtBasic();
  47.     SetPtBasic(const SetPtBasic& setpt);
  48.     virtual ~SetPtBasic();
  49.    
  50.         SetPtBasic& operator = (const SetPtBasic& setpt);
  51.  
  52.     void SetPtV (std::vector<PtBasic*> ValPt);
  53.     std::vector<PtBasic*> GetPtV () const;
  54.  
  55.     PtBasic* at_pb (unsigned int i) const; // acces au vecteur de point
  56.     virtual void push_back (PtBasic* ValPt); // ajout au vecteur de point
  57.     void erase (unsigned int i);
  58.  
  59.     unsigned int size() const;
  60.     void resize(unsigned int size);
  61.     bool empty() const;
  62.    
  63.     Plan   PlanMoyen  (std::ostream& out) const;
  64.     double ZMoyen     (std::ostream& out) const;
  65.     double ZMoyenPond (std::ostream& out, PtBasic PtRef, double dmax) const;
  67. private:
  68.     std::vector<PtBasic*> Pt;
  69. // le vecteur et maintenant privé pour eviter les fausse manip depuis les fonnctions exterieures
  71. };
  74. class PtCal : public PtBasic
  75. {  
  76. public :
  77.     PtCal();
  78.     PtCal(const PtBasic& pt);
  79.     PtCal(const PtCal& pt);
  80.     virtual ~PtCal();
  81.    
  82.     PtCal& operator = (const PtCal& pt);
  83.    
  84.     std::string Nom() const;
  85.    
  86.     double Ex() const;
  87.     void SetEx(double value);
  88.     void AddToEx(double value);
  89.    
  90.     double Ey() const;
  91.     void SetEy(double value);
  92.     void AddToEy(double value);
  93.    
  94.     double Ez() const;
  95.     void SetEz(double value);
  96.     void AddToEz(double value);
  97.    
  98.     bool Known() const;
  100.     PtBasic MakeItBasic() const;
  101.    
  102.    
  103.    std::string nom;
  104.    bool connu;
  105.     double ex, ey, ez;
  106. };
  108. bool operator == (const PtCal& a, const PtCal& b);
  109. bool operator != (const PtCal& a, const PtCal& b);
  112. class SetPtCal : public SetPtBasic
  113. {
  114. public :
  115.     SetPtCal ();
  116.     SetPtCal (const SetPtCal& setpt);
  117.     virtual ~SetPtCal ();
  118.    
  119.     SetPtCal& operator = (const SetPtCal& setpt);
  120.  
  121.     PtCal* at_pc(unsigned int i) const; //nouvelle interface d'acces pour recuperer les pt cal
  122.     virtual void push_back(PtBasic* ValPt);
  123.  
  124.     void LoadPtCal (std::string nomfcalage);
  125.     void SavePtCal (std::string nomfcalage) const;
  126.  
  127.     void AddPtCal  (std::string nomfcalage);
  128.     void AddPtCal  (PtCal pt);
  129.  
  130.     bool  PtInc (std::string nompoint) const;
  131.     unsigned int GetPt (std::string nompoint) const;
  132.  
  133.     void PrintNXYZEXYZ (std::ostream& out) const;
  134.     void PrintNXYZ (std::ostream& out) const;
  135. };
  137. std::vector<PtBasic*> LoadFPtCal (std::string nomfcalage);

*
 
voila finalement ce qui est sortit de mon esprit enfumé...
 
le vecteur et privé et on accede au element par interface at_pb() et at_pc()
dans et_pc() il y a un dynamique_cast
et dans la fonction virtuelle push_back SetPtCal verifie par dynamic_cast que les objets pusher sont bien des PtCal*
 
a priori ca marche...
 
YOP

n°1157394
bjone
Insert booze to continue
Posté le 22-07-2005 à 16:20:06  profilanswer
 

c'est cool ton truc, mais c'est un peu une usinage à gaz ?
j'ai pas cherché à comprendre ton intention, mais par exemple si c'est un vecteur de vertex (point x,y,z et autres affinitées) que tu stoques, mois je ferais une class Vertex basique sans rien de virtuel...  
 
Et après tu fais un VirtVertex ou j'en sais rien avec tes interfaces en virtual....
 
tu mets ça en vector<> pour avoir un truc simple, et une hash_map<string,int> pour résoudre l'indice d'un vertex par son nom, voir un vector<string> en parallèle pour éviter de polluer le cache....
 
enfin ce que j'en dis, je sors ->[]

mood
Publicité
Posté le   profilanswer
 


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C++

  pb de conception orientée objet

 

Sujets relatifs
Inserer objet Media Player dans une pageOptimisation d’un modèle (objet) 3D (Diminution du nombre de face)
Changer une classe d'un objet input [Résolu]problème spécifique de conception d'une base
Doublon dans un tableau d'objetcréer un objet d'un element de base de données.
[Delphi] Copier Objet (Assign) ?Conception orienté objet autour d'une BD
problème d'objet 
Plus de sujets relatifs à : pb de conception orientée objet

Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo
Page générée en 0.207 secondes

Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR