Discussion :

[Nico65]

j'aimerais bien faire un truc un peu special, que je decris dans ce petit bout de code. Oui oui je sais que deux instances de A sont cr��es dans la cr�ation de C, c'est bien ce que je veux

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
 
#include <iostream>
 
using namespace std;
 
class A {
public:
  A() {
    cout << "A created" << endl;
  }
 
  virtual void method() = 0;
};
 
class B : public A {
public:
  void method() {
    cout << "method B" << endl;
  }
};
 
class C : public B, public A {
public:
  void method() { // la je veux redefinir A::method()
    cout << "method C" << endl;
  }
};
 
void func(A & a) {
  a.method();
}
 
int main() {
  C c;
  func(c);
}

mais le compilo il veut pas :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
 
inheritance.cpp:21: warning: direct base `A' inaccessible in `C' due to 
   ambiguity
inheritance.cpp: In function `int main()':
inheritance.cpp:34: error: `A' is an ambiguous base of `C'

bon vous avez compris ce que je veux faire

Vous me direz que ce n'est pas propre mais je ne vois pas le probl�me de conception moi, dans C il suffirait de sp�cifierA:: ou B::A:: pour avoir un acc�s non ambigus a tous les membres...
qu'est ce que vous en dites ? comment r�soudre ce "probl�me" ?

[jmv]

C h�rite de B et de A (h�ritage multiple, d�conseill�) Est-ce n�cessaire ?
Je pense que ce que tu voulais est que :
- B h�rite de A,
- C h�rite de B (donc aussi de A)

Ca marchera mieux avec :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
class C : public B // et pas A
{ 
public: 
  void method() { // la je veux redefinir A::method() 
    cout << "method C" << endl; 
  } 
};

[CroustRyu]

Dans ce cas n'oublie pas de d�clarer "method" en virtual dans B

[Nico65]

oui... mais non. Je voulais bien que C herite de B (qui h�rite de A) et d'une autre instance de A. De 2 instances de A quoi en quelque sorte. Mais attention C s'en fiche completement de B::A, tout ce qui l'interesse c'est un acc�s a B et un a A

pourquoi ?
prenons un exemple (pratique) :

B h�rite de Thread (comme en java)
C h�rite de Thread aussi

ce sont 2 threads qui n'ont aucun rapport l'un avec l'autre. Pour autant, pourquoi C ne devrait pas h�riter de B ?

en Java cette solution est rendu possible (je crois) par les interfaces (Runnable en l'occurence) mais ya pas d'interface en C++ alors comment faire ?

[CroustRyu]

Si tu h�rites de B sans aucun but pr�cis, autant ne pas le faire.

En java l'utilisation d'interface te permet de d�finir des sortes de contrat, mais ne t'offres pas la possiblit� de r�utiliser du code.

[Nico65]

Si tu h�rites de B sans aucun but pr�cis, autant ne pas le faire

au contraire, il est tout naturel dans ma conception objet que C herite de B
mais si j'ai bien compris de toute facon j'ai pas le choix... enfin merci quant meme

[jmv]

essaye �a:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
class B : public virtual A {
...
class C : public B, public virtual A {
...

d�sol� je peux pas essayer chez moi, et l'h�ritage multiple n'est pas ma tasse de th�, d'ailleurs je ne suis toujours pas convaincu de la n�cessit� d'un h�ritage multiple ici.

pour les interfaces: en C++ ce sont des classes qui ne contiennent que des m�thodes virtuelles pures.

[jmv]

il est tout naturel dans ma conception objet que C herite de B

si C h�rite de B et que B est un thread, alors C est un thread, pas besoin d'h�ritage multiple (ou alors un truc m'�chappe )

[CroustRyu]

ou alors un truc m'�chappe

Pareil pour moi

[Nico65]

mais je veux que C soit un autre thread

bon t'as peut-etre raison, C ne devrais peut-etre pas h�riter de B...

[jmv]

mais je veux que C soit un autre thread

mais �videmment que ce sera un autre thread. Les instances d'une classe sont ind�pendantes (enfin... normalement), seules les m�thodes sont communes.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
B b1, b2, b3; // 3 threads
C c1, c2; // 2 autres threads

Attention tout de m�me � d�clarer virtuelle la m�thode �x�cut� par le thread (run() ou execute() ?)

bon t'as peut-etre raison, C ne devrais peut-etre pas h�riter de B...

non, je pense que C doit h�riter uniquement de B.

[Nico65]

bon quelqu'un lui explique moi je fatigue...
je veux que la creation de 1 C cr�e 2 thread (un pour C et un pour B)

je retravaille sur mon modele avec B comme membre de C a la place

[moldavi]

oui... mais non. Je voulais bien que C herite de B (qui h�rite de A) et d'une autre instance de A. De 2 instances de A quoi en quelque sorte. Mais attention C s'en fiche completement de B::A, tout ce qui l'interesse c'est un acc�s a B et un a A

Je vais surement dire une b�tise, mais selon ta conception j'aurais fait ceci:

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
 
class A {
 
  public:
    A() {
      cout << "A created" << endl;
    }
 
    virtual void method() = 0;
};
 
class B : public A {
 
  public:
    void method() {
      cout << "method B" << endl;
    }
};
 
class C : public A{
 
  public:
    void method() { // la je veux redefinir A::method()
      cout << "method C" << endl;
    }
    B* b;
};

[jmv]

bon quelqu'un lui explique moi je fatigue...

maisheuuuuu

je veux que la creation de 1 C cr�e 2 thread (un pour C et un pour B)

l� c'est clair (je savais bien qu'un truc m'�chappait), dans ce cas c'est pas un h�ritage qu'il te faut, mais une composition. voir le post de moldavi.

[moldavi]

Vous me direz que ce n'est pas propre mais je ne vois pas le probl�me de conception moi, dans C il suffirait de sp�cifierA:: ou B::A:: pour avoir un acc�s non ambigus a tous les membres...
qu'est ce que vous en dites ? comment r�soudre ce "probl�me" ?

Pour toi c'est �vident mais malheureusement le compilateur il ne r�fl�chit pas comme toi.

En effet lorsque tu fais A:quelquechose) ou B:autrechose), tu n'as pas l'impression que c'est ambig� dans ta t�te. D�j� r�fl�chis un peu � ce qu'il se passe lorsque tu utilises une r�f�rence sur une classe avec des h�ritages de partout (BEN c'est le bordel). Mais saches que pour compiler du code, il ne doit y avoir aucune ambiguit�. On a pas encore invent� le compilo qui fait "Plouf-Plouf �a sera toi que je prendrais"...

[axile]

Ce serait plus simple que ta classe C soit un A, mais qu'elle contienne un B.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
class C : public A { 
public: 
  B     b;
  void method() { // la je veux redefinir A::method() 
    cout << "method C" << endl; 
  } 
};

Je ne crois pas que Java te permettrait d'avoir deux m�thodes identiques. C'est ce que tu obtiens en h�ritant � la fois de A et de B. Tu as deux fonctions method().

[JolyLoic]

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
 
#include <iostream>
 
using namespace std;
 
class A {
public:
  A() {
    cout << "A created" << endl;
  }
 
  virtual void method() = 0;
};
 
class B : public A {
public:
  void method() {
    cout << "method B" << endl;
  }
};
 
class C : public B, public A {
public:
  void method() { // la je veux redefinir A::method()
    cout << "method C" << endl;
  }
};
 
void func(A & a) {
  a.method();
}
 
int main() {
  C c;
  func(c);
}

Tout probl�me de g�nie logiciel peut se r�soudre � l'aide d'un niveau d'indirection suppl�mentaire

Le seul moyen que je connaisse pour red�finir une fonction virtuelle avec de l'h�ritage en diamant est de passer par une/des classe(s) interm�diaires :

Quand tu veux �crire la classe C, tu peux �crire une classe C_From_B d�rivant de B et red�finissant A::m�thode pour cette instance de A dans le C final, et une autre classe C_From_A d�rivant drectement de A et faisant de m�me. Ta classe C d�rive alors de C_From_B et de C_From_A.

[SKZ81]

Pour le probl�me de conception :
-Est-ce que C doit cr�er un thread ?
-O� doit il �tre un thread ?

Pour pas me casser, j'aurais fait (mais pas s�r d'avoir tout compris, mais tant pis)

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
 
class Thread; // possède une "methode()" virtuelle pure.
 
class ThreadA {
... methode() {...}... // on redéfinie la méthode pour A
};
 
class ThreadB {
... methode() {...}... // idem pour B
};
 
class QuiCreeDeuxThreadsQuelconques {
...
  Thread * t1;
  Thread * t2;
...
}
 
class UneAutrePourLeFun {
...
  ThreadA ta;
  ThreadB tb;
...
};

L� �a me para�t plus propre. Fin, ce que j'en dis, pour ce que j'ai compris au probl�me.

Ce qui se con�oit bien s'exprime clairement, et les mots pour le dire viennent ais�ment

NB : en passant sur ce qui a �t� dit au sujet du mot-clef vitrual. Ce me semble �tre des b�tises. Comment vouler vous red�finir une m�thode virtuelle, pure de surcro�t, par une m�thode classique, "statique" (au sens de "dont l'adresse pourra �tre r�solue � la compilation", pas celui de "m�thode de classe") ?
Je ne dis pas que c'est un mauvaise chose de le pr�ciser, au contraire, mais y'a pas de risque � l'oublier, je pense...

[Nico65]

bon alors SKZ81, toi tu as la palme, j'ai rien compris a ton code par rapport a mon probleme

Pour le probl�me de conception :
-Est-ce que C doit cr�er un thread ?
-O� doit il �tre un thread ?

je vais me faire tuer, mais j'ai bien du mal a voir la difference... quant tu cree un chien, tu cree un animal. Que le chien soit un animal, ca a une importance pour ton code mais surtout pour ton modele

l'exemple des thread etait pas bon, alors admettons qu'une A contient une ressource partagee "x", protegee par un mutex. Les autres classes peuvent bloquer aussi ce mutex pour avoir un acces exclusif a "x". Deux choix (c'est un peu du peudo-code) :

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
 
void func() {
   ...
   a.lock();
   X x = a.getX();
   ... // use x
   a.unlock();
}
 
class A1 {
   Mutex mutex;
   X x; 
 
   void uneMethodeQuelconqueQuiUtiliseX() {
      lock();
      ...
      unlock();
   }
 
   void lock() {mutex.lock();}
   void unlock() {mutex.unlock();}
}
 
class A2 : public Mutex {
   X x;
 
   void uneMethodeQuelconqueQuiUtiliseX() {
      lock();
      ...
      unlock();
   }
   X getX() {return x;}
}

enfin bref vous avez compris

[JolyLoic]

La deuxi�me m�thode est mauvaise :

On pourra passer � une fonction inf f(Mutex &) un objet du type A2, alors que �a n'a pas vraiment de sens.

Si A2 h�rite d'un Mutex, �a signifie en terme de conception qu'un objet de type A2 est un Mutex. Pour mod�liser un lien de type A2 utilise un Mutex, tu as la composition, comme tu l'as marqu�e, ou dans des cas particuliers l'h�ritage priv�.