Héritage et accès aux données

Version imprimable

19/07/2006, 10h23
spetit

Héritage et accès aux données
Bonjour,

J'aurai une question par rapport à l'héritage de classe.
J'ai une classe mère Solution dans laquelle j'ai des données "protected" et une classe fille SolPVL.
Code:

1 2 3 4 5 6 7 8 9 10 class Solution { protected: int nbLig; ... } class SolPVL : public Solution { ... }
Si j'ai bien compris, mes données protected de Solution devraient alors être aussi protected dans SolPVL, non ?

Pourtant, si j'appelle nbLig depuis une fonction de SolPVL, j'obtiens l'erreur suivante à la compilation :

Citation:

/home/spetit/logiciel/include/solution.hpp:44: error: `int Solution::nbLig' is protected
solPVL.cpp:189: error: within this context

Est ce que ça peut venir du compilateur (g++, j'ai essayé avec les versions 3.3.6 et 4.0.1).
Y a t'il une autre solution que de mettre toutes les données en public (j'ai essayé et pas d'erreur dans ce cas).

Merci.
Stéphanie
19/07/2006, 10h38
Eusebe

C'est bizarre... chez moi je n'ai pas eu ce type de problème... (avec GCC comme compilateur)
Est-ce que tu peux nous donner un code minimal qui reproduit cette erreur ?

Dans une classe fille, tu n'as pas accès aux données protected d'un autre objet.

Ce que tu peux faire, c'est un pseudo-accesseur protected static (inline pour optimiser) dans la classe mère, qui te permette d'accéder aux données de l'autre objet.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 class Solution { protected: int nbLig; static inline int GetNbLig(Solution const &sol) { return sol.nbLig; } } class SolPVL : public Solution { void UneFonction(Solution & sol) { int nLig = GetNbLig(sol); } }

19/07/2006, 13h37
poukill

????

Les membres protected sont vu comme public en interne dans la classe, et private à l'extérieur, non ???
Donc une classe fille devrait y avoir accès.8O
19/07/2006, 13h48
Eusebe

Citation:

Envoyé par poukill

Donc une classe fille devrait y avoir accès.8O

Oui, oui, l'instance d'une classe fille y a accès.
Mais une instance d'une classe fille n'a pas accès aux membres protected d'une autre instance de la même classe fille. Je crois que c'est ce que voulais dire Médinoc.
19/07/2006, 13h55
Médinoc

J'ignore si c'est dans la norme, mais c'est en tout cas ce que j'ai constaté.

Il semblerait qu'on n'ait accès aux variables protected/private d'un objet extérieur que dans la même classe, et non pas dans les classes parentes/dérivées.
19/07/2006, 14h03
rigobert

Citation:

Envoyé par Eusebe

Oui, oui, l'instance d'une classe fille y a accès.
Mais une instance d'une classe fille n'a pas accès aux membres protected d'une autre instance de la même classe fille. Je crois que c'est ce que voulais dire Médinoc.

8O Je ne crois pas.

D'ailleurs les droits d'accès aux membres (privés/protégés/publics) n'ont rien à voir avec les instances: toutes les instances d'une classe donnée se comportent rigoureusement de la même façon !

C'est au niveau des déclarations des différentes classes que ça se joue.
19/07/2006, 14h06
Médinoc

Si on a le même résultat avec g++ (Eusebe) et Visual (moi), c'est qu'il doit en être ainsi dans la norme.

Les accès "n'ayant rien à voir avec les instances" ne se propagent pas vers les classes filles.
19/07/2006, 14h11
Eusebe

Citation:

Envoyé par rigobert

D'ailleurs les droits d'accès aux membres (privés/protégés/publics) n'ont rien à voir avec les instances: toutes les instances d'une classe donnée se comportent rigoureusement de la même façon !

Ah bon ?

Tu veux dire que chez toi si tu définis une classe A avec un membre privé a, l'objet A1 peut directement agir sur le membre a de l'objet A2 (A1 et A2 étant des instances de A) ?

On ne dois pas avoir les mêmes compilateurs alors ;)
19/07/2006, 14h22
Médinoc

Eusèbe : Normalement, ça, c'est permis.
C'est ce qui permet entre autres de simplifier le constructeur de copie pour ne pas avoir à utiliser des accesseurs pour les variables privées, par exemple.

Citation:

Envoyé par Eusebe

Ah bon ?

Tu veux dire que chez toi si tu définis une classe A avec un membre privé a, l'objet A1 peut directement agir sur le membre a de l'objet A2 (A1 et A2 étant des instances de A) ?

On ne dois pas avoir les mêmes compilateurs alors ;)

Soit on ne parle pas de la même chose, soit j'en perds mon latin :?

Chez moi (VC 7.1), ceci fonctionne sans problème:
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 class A { public: void Test1 (const A& aaa) { Fonction1 (aaa); } void Test2 (A& aaa) const { Fonction2 (aaa); } private: int a; void Fonction1 (const A& aaa) { a = aaa.a; } void Fonction2 (A& aaa) const { aaa.a = a; } }; int main() { A a0; A a1; a0.Test1 (a1); a1.Test2 (a0); return 0; }

19/07/2006, 14h27
poukill

Citation:

Eusèbe : Normalement, ça, c'est permis.

Ha bon ??? Sérieux?
19/07/2006, 14h30
Médinoc

Rigobert: Oui, ça, ça marche.
C'est quand il y a de l'héritage que ça se complique.

Citation:

Envoyé par Médinoc

Rigobert: Oui, ça, ça marche.
C'est quand il y a de l'héritage que ça se complique.

Ok, je préfère ça, j'ai cru être passé un moment dans la 4ème dimension :D

Maintenant, j'ai essayé ça, qui me parait correspondre au problème tel qu'il a été posé au départ :
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 class A { protected: int a_x; }; class B : public A { public: void Test1 (B& b) const { Fonction1 (b); } void Test2 (const B& b) { Fonction2 (b); } protected: int b_x; void Fonction1 (B& b) const { b.a_x = a_x; b.b_x = b_x; } void Fonction2 (const B& b) { a_x = b.a_x; b_x = b.b_x; } }; int main() { B b0, b1; b0.Test1 (b1); b1.Test2 (b0); return 0; }
Et ça fonctionne aussi sans problème sous VC7.1

Voici un exemple qui montre le problème.
Les lignes en commentaires sont celles qui échouent forcément, puisqu'on s'attaque à du private de la clase mère.
La ligne en gras est celle qui met en évidence le problème.

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
53
#include <iostream>
using namespace std;

class CBase
{
private:
	int m_privBase;
protected:
	int m_protBase;
public:
	int m_pubBase;
};

class CDerivee : public CBase
{
private:
	int m_privDeriv;
protected:
	int m_protDeriv;
public:
	int m_pubDeriv;

void Fonction(CDerivee *pObj);
};


void CDerivee::Fonction(CDerivee *pObj)
{
cout << "Valeurs perso :" << endl;
cout << m_privDeriv;
cout << m_protDeriv;
cout << m_pubDeriv;
//cout << m_privBase;
cout << m_protBase;
cout << m_pubBase;
cout << endl;

cout << "Valeurs de l'autre :" << endl;
cout << pObj->m_privDeriv;
cout << pObj->m_protDeriv;
cout << pObj->m_pubDeriv;
//cout << pObj->m_privBase;
cout << pObj->m_protBase;	//ici, ça marche
cout << pObj->m_pubBase;
cout << endl;

cout << "Valeurs de l'autre (base)  :" << endl;
CBase *pBase = pObj;
//cout << pBase->m_privBase;
cout << pBase->m_protBase;	//ici, ça foire
cout << pBase->m_pubBase;
cout << endl;
}

Le tout, testé sous Visual C+ 8.0 et gcc version 2.95.4 20020320 [FreeBSD]

Oups, au temps pour moi, rigobert :aie: :aie:

En fait, j'avais testé ça sur des classes héritées, et ça ne fonctionnait pas :/ Va falloir que je me repenche sur le sujet...

Désolé :hola:

Médinoc, je viens de tester ce code, et ça compile aussi :
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 class B { protected: int a; }; class A : public B { public: void Test1 (const A& aaa) { a = aaa.a; } void Test2 (A& aaa) const { aaa.a = a; } }; int main() { A a0; A a1; a0.Test1 (a1); a1.Test2 (a0); return 0; }
Edit : grilled...

19/07/2006, 14h49
Médinoc

J'ai mis un moment à reproduire le problème, car au début ça marchait.
C'est ensuite que j'ai compris qu'il fallait un pointeur sur la classe de base.
19/07/2006, 14h53
Eusebe

Citation:

Envoyé par Médinoc

J'ai mis un moment à reproduire le problème, car au début ça marchait.
C'est ensuite que j'ai compris qu'il fallait un pointeur sur la classe de base.

En effet, c'est bien ça que j'avais essayé dans ma programmation, et qui ne fonctionnait pas (d'où ma conclusion un peu hative...).
19/07/2006, 15h08
rigobert

Citation:

Envoyé par Médinoc

J'ai mis un moment à reproduire le problème, car au début ça marchait.
C'est ensuite que j'ai compris qu'il fallait un pointeur sur la classe de base.

En tout cas l'hypothèse du bug est peu plausible si ça le fait sur plusieurs compilos (au moins 3).
D'un autre côté ça parait un peu space comme spécification (de la norme C++)...
19/07/2006, 15h57
spetit

Merci beaucoup pour toutes vos réponses, elles m'ont aidée à bien comprendre ce qu'il se passait. J'ai essayé de mon côté de faire un exemple pour vous montrer mais Médinoc a été plus rapide : c'est bien l'équivalent de la ligne en gras de son code qui me posait problème.
Je vais donc faire des fonctions get pour les quelques variables de la classe mère dont j'ai besoin dans la classe fille.
Merci !
Stéphanie

Les règles pour l'accès protected sont un peu complexes. Le standard dit la chose suivante (11.5-1) :

Citation:

L'accès doit se faire par un pointeur, une référence ou un objet de la classe dérivée elle même.

En clair, si on a :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 class B { protected : int i; }; class D1 : public B { }; class D2 : public B { void f(D1* pd1) { i=1; // ok pd1->i = 2; // interdit, il s'agit d'une autre classe dérivée } };

Citation:
Envoyé par roulious
Les règles pour l'accès protected sont un peu complexes. Le standard dit la chose suivante (11.5-1) :

En clair, si on a :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 class B { protected : int i; }; class D1 : public B { }; class D2 : public B { void f(D1* pd1) { i=1; // ok pd1->i = 2; // interdit, il s'agit d'une autre classe dérivée } };
:( lapin compris...

19/07/2006, 16h36
Eusebe

Citation:

Envoyé par rigobert

:( lapin compris...

Moi, si j'ai bien compris, et en reprenant l'exemple de roulious, "i=1", on peut parce que cela correspond à "this->i" et que "this" est un pointeur sur D2.

Par contre "pd1->i" on ne peut pas parce que ce n'est pas un pointeur sur D2 mais sur D (et que l'on est dans la classe D2).
19/07/2006, 17h53
rigobert

Citation:

Envoyé par Eusebe

Moi, si j'ai bien compris, et en reprenant l'exemple de roulious, "i=1", on peut parce que cela correspond à "this->i" et que "this" est un pointeur sur D2.

Par contre "pd1->i" on ne peut pas parce que ce n'est pas un pointeur sur D2 mais sur D (et que l'on est dans la classe D2).

Je parlais de roulious.

"pd1->i = 2" n'est pas possible parce que c'est une classe différente, point !!

Rien à voir avec le problème mis en évidence par Medinoc...
19/07/2006, 18h57
roulious
La citation du standard était correcte, mais mon exemple est pourri, désolé. Le problème de Medinoc tombe sous le coup du standard :
Code:

1 2 3 4 5 6 void CDerivee::Fonction(CDerivee *pObj) { CBase *pBase = pObj; pBase->m_protBase; // accès interdit }
L'accès à m_protBase se fait par un pointeur sur CBase et non pas par un pointeur de la classe dérivée elle même, ici CDerivee. D'où l'accès interdit, et un accès autorisé en faisant
Code:

1 2 3 4 5 void CDerivee::Fonction(CDerivee *pObj) { pObj->m_protBase; }
puisqu'on passe par un pointeur sur CDerivee.

Même si pBase pointe sur un objet de type CDerivee, et qu'on peut y accéder sans problème par un static_cast ou un dynamic_cast, son type est nénamoins CBase*