comment savoir ce que fait mon pointeur??

bonjour,
j'ia un petit probleme que voici.
soit une classe abstraite B, et deux classe derivée de B.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Class B { ***() =0; }   class D1 : public B { ***(); }   class D2 : public B { ***(); }

---

soit aussi un poiteur p qui pointe sur la classe abtraite.

Code:

---

1 2 3 4

class Q{ Base* p; }

---

et il y a un moment dans le code, j'aimerais soivoir sur quoi poite p;,
je m'explique,


en fait j'aimerais faire ca

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

class Q{ Base* p; Q& operator=(const Q& X) { if(si this->p pointe sur D1 et X.p pointe aussi sur D1) alors faire ca{} else if(this.p pointe sur p1 et X.p pointe sur D2) alors faire ca. etc...Etc...etc... } est ce possible???     merci   j'espere avoir été assez clair.   a+++     }

---

Il faut voir avec dynamic_cast, qui renverra NULL si le downcasting est mauvais (càd si le type dérivé n'est pas celui qu'on croit), et qui convertira bien en classe dérivée dans le cas contraire.

Mais pour la copie peut-être peux-tu t'inspirer du design pattern du clone ?

http://c.developpez.com/faq/cpp/?pag...es#CLASS_clone

mais en fait, la classe abstraite est appelée struc_trier_abs, et les classes derivées sont soit Arbre Binaire, soit Vecteur Trier.

pour j'emploi le clonage si c'est un Vecteur Trier dnas un vecteur Trier ou bien
un AB dnas un AB. mais si c'est un AB dnas un Vecteur, j'ai pas l'air con.

merci

a++

Si tu affectes quelque chose qui contient un arbre à quelque chose qui contient un vecteur, il sera normal que ce dernier vire son vecteur et prenne un arbre non ? C'est justement le but de ce genre de pattern, masquer l'implémentation derrière un pointeur sur une classe abstraite, et pouvoir la changer à la volée.

non rien en fait.


pour le prob AB dans un V, justement non, il vuex que tout les element de l'arbre aille dans le vecteur.

merci
quand meme

en fait voici ma fonction

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

template <class T> struc_tri<T>& struc_tri<T>::operator=(struc_tri<T>& X) { if(this != &X) { if(this->p->Que_suis_je() == X.p->Que_suis_je()) { delete p; p = X.p->Copy(); } else if(this->p->Que_suis_je() == 0 && X.p->Que_suis_je() == 1) { delete p; X.Parcours(F); } else{}   } return *this; }

---

en fait, c'est operateur gal, et en fonction de ce qu'il y a a gauche, et a droite, il doit faire des choses differentes.

pour les,
if (this->p->Que_suis_je() == X.p->Que_suis_je()
je dois faire quoi ceci if(dynamic_cast<classeD1>this.p) == dynamic_cast<classeD2>X.p) alors, pointe sur meme obj???

merci

a++

Faire un double-dispatch au moment de l'affectation me parait hyper louche.

Quels que soient les types effectifs des ressources de deux objets, après affectation de l'un vers l'autre il faut s'attendre à ce qu'ils soient égaux. Soit, on n'a rien à faire des types dynamiques exacts des ressources lors des copie et affectation.

Soit, ceci devrait suffire:

Code:

---

1 2 3 4 5 6 7 8 9 10

T & T::operator=(T const & rhs) { T tmp(rhs); swap(tmp); return *this;}   T(T const & rhs) : p_(rhs.p_->clone()) {}   ~T() { delete p_; }   void T::swap(T & other) { std::swap(p_, other.p_); }

---

Et il n'y a aucun test.

(d'ailleurs l'idiome de la protection contre la copie de soi-même est insuffisant et inutile quand on code à l'endroit)

non justement, c'est ce que je dit.

soit struc_tri P() // dans arb_binaire
soit struc_tri Q(20) // dans dans vecteur de 20
bon je les rempli comme je veux , et apres que je fasse P=Q
p ne dois pas devenir un vecteur, il doit rester un AB, mais avec les valeurs de Q, suis je clair???

merci

ce n'est pas un op d'affectation type, c'est pour aprrendre quoi .

est ce assez clair. merci
a++

Cela n'a pas de sens, d'utiliser op= pour ça.
Surtout si P et Q ont le même type. Mais bon, supposons que tu utilises un nom moins ambigue. Par exemple reset_from().
On peut s'en sortir en bidouillant (comprendre qu'il y a très probablement un problème dans le design).

Le principe (propre) consiste à définir une interface commune pour tes ressources. Interface dont tu pourras extraire les informations qui te permettront de construire des spécialisations. 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 50 51 52

struct ressource { virtual ~ressource() {} virtual ressource * clone() const = 0;   virtual information get_info() const = 0; ... autres fonctions à spécialiser ... virtual void reset_from(information const&) = 0; void reset_from(ressource const& rhs) { reset_from rhs.get_info(); } private: ressource & operator=(ressource const &); // affectation interdite };   struct ressource_spe : ressource { ressource_spe(information const & info) : ... { ... } ressource_spe(ressource_spe const & rhs) : ... { ... } virtual ressource * clone const() {return new ressource_spe(rhs);}   virtual information get_info() const { return information( .... ); }   virtual void reset_from(information const& info) { ressource_spe tmp(rhs); swap(tmp); } void swap(ressource_spe & other) { ... }   ... autres fonctions que l'on spécialise ... private: ... la ressource réellement enveloppée ressource_spe & operator=(ressource_spe const &); // op= interdit };   struct truc { truc() : ressource_(0) {} truc( ......) : ..... { .... } ~truc() { delete ressource_; }   truc( truc const & rhs) : ressource_(rhs.ressource_->clone()) {} truc & operator=(truc const &rhs) // impl classique { truc tmp(rhs); swap(tmp); return *this} void swap(truc & other) { ressource_.swap(other.ressource_); }   void reset_from(truc const & rhs) { ressource_->reset_from(rhs.ressource_); } private: ressource * ressource_; };

---

Dans ton cas, ressource_spe serait une classe template qui utiliserait en sous-main l'un des conteneurs de la SL. information un type itérateur utilisé avec l'idiome enveloppe-lettre -- information doit avoir une sémantique de valeur dans ce code..

Bref, c'est inutilement compliqué. Ton problème est louche.


L'autre solution à coups de dynamic_cast<> est rapidement non maintenable (car non extensible sans modification) et est typique des cas où les interfaces des objets sont trop dissemblables pour être stockés ensemble.
C'est à réserver, ici, au cas où tu ne pourrais pas définir la classe, éventuellement abstraite, information.

Deux objets a et b sont de même type si dynamic_cast<Spe*>(a) && dynamic_cast<Spe*>(b). Et-logique entre deux infos qui sont non nulles si le (down)casting vers le type spécialisé est possible.

MEA COULPA

je me suis renseigner aupres de mon prof, et en fait, c'est au choix de l'interpretation,

donc, on peux changer la structure de l'assignation dans le gauche.


grand merci

a++