Discussion :

[camboui]

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
struct C_Base
{
private:
 ...
public:
 ...
 virtual void M()=0;//all overloaded M() should access private members of Autre
};
 
struct C_Derive1: C_Base
{
private:
 ...
public:
 ...
 virtual void M();//need to access private members of Autre
};
 
struct Autre
{
 friend struct C_Base;
private:
 ...
public:
 ...
};

Je souhaiterais qu'une classe de base, et toutes ses dérivées, soient "friend" d'une Autre classe. Mais je voudrais éviter d'avoir à spécifier la liste des classes dérivées à Autre.
Une solution à cela ?
Merci.

[white_tentacle]

Pas de solution simple à ma connaissance, c'est une limitation de friend.

Il y a peut-être un moyen de bricoler à base de friend template, en définissant tes classes dérivées comme spécialisation d'un type template. Je déconseille très fortement d'en arriver à une telle solution .

Expose un peu plus en détail pourquoi tu aurais besoin de faire ça, et dans ce cas, on pourra t'orienter vers une solution plus propre (certains vont te dire que dès qu'il y a friend, ce n'est pas propre, personnellement, je ne partage pas du tout cet avis).

[Davidbrcz]

Ca me semble difficile vu que l'amitié n'est ni héritée, ni transitive ou réciproque.

Edit: +1 pour expliciter les besoins, ca sent la mauvaise conception.

[koala01]

Salut,

Ceci dit, toute fonction définie au sein de cette classe et non redéfinie dans les classes dérivées (donc a priori, les fonctions non virtuelles, et, pour qu'elles soient accessibles depuis les classes dérivées, déclarées publique ou protégées) sont réputé etre... de la classe de base...

Aussi, si tu déclare la classe de base amie de ta classe Autre, et que tu définis les fonctions qui vont "profiter" de l'amitié dans la classe de base de manière non virtuelle et publique ou protégées (mais pas privée), tu pourra invoquer ces fonctions depuis les autres fonctions des classes dérivées

[camboui]

J'explique, en espérant me faire comprendre, sans rentrer dans de longs et fastidieux détails

J'ai une db SQL avec plein de tables. Rien de bien excitant, sauf qu'une de ces tables est du genre fourre-tout. Elle contient 3 champs principaux: "type", "subtype" et "data". En fait, le propriétaire des données, chaque fois qu'il a besoin de créer un contenu "secondaire" dans sa db, au lieu de créer une table (tâche sous-traitée et donc fastidieuse et coûteuse) il remplit cette table en créant un nouveau type. En gros il crée lui-même dynamiquement des "tables", le nom de la (fausse) "table" se trouve dans "type", les champs dans "subtype", et l'info correspondante dans "data".
En fait il me semble que ce soit assez classique comme modèle fourre-tout.

Pour gérer le contenu de cette table j'ai écrit une classe C++ qui l'encapsule.
Mais comme les choses ne sont jamais simples, il y a de nombreux cas d'exception dans le traitement des données qui sortent du cas générique. J'ai donc créé une classe de base pour gérer le cas générique, classe amie de la classe d'encapsulation principale, puis au fur et à mesure de l'enrichissement du contenu, je crée une classe dérivée lorsque ce contenu sort du cadre générique. La classe de base et les classes dérivées doivent accéder à certaines infos privées de la classe d'encapsulation principale.

Je pourrais déplacer de private vers public les champs nécessaires, mais seule la liste des classes dérivées peuvent y accéder.
Donc pour l'instant chaque classe dérivée créée est aussi ajoutée dans la liste des classes friend. Bah, c'est pas bien grave, mais ça me fait bizarre.

Si vous avez d'autres idées, merci

[JolyLoic]

Tu pourrais donner à ta classe d'encapsulation deux interfaces, une qui ne contient que les fonctions publiques, et que tu donnes à tes clients standards, et une autre contenant les fonctions de manipulation avancées (qui sont actuellement en privé dans ta classe), mais que tu ne passe qu'à ta hiérarchie de classe de manipulation.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

class MonEncapsulation : public InterfacePublique, public InterfacePrivée {...}

Ou une variante, mais encapsule moins, mais demande une classe de moins, et évite l'héritage multiple (certains sont peu à l'aise avec) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
class MonEncapsulation : public InterfacePublique
{
  // Et là, tu mets tout en public:
}

Tu dois aussi pouvoir fonctionner par composition, la classe englobante étant fournier publiquement, et contenant un pimpl vers une classe dont le .h n'est pas fourni au client de la classe

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
class MonImplementationOuToutEstPublique;
class InterfacePublique
{
  scoped_ptr<MonImplementationOuToutEstPublique> monImplementation;
}

[camboui]

Merci pour vos réponses.

Etant dans un contexte de maintenance, il est difficile de tout chambouler. L'idée de koala01 me semble la plus simple et la plus adaptée.
Et après réflexion, je pense que c'est une solution générale qui peut s'appliquer dans de nombreux contextes: confier à la classe de base l'essentiel des accès extérieurs.

Encore merci.

[koala01]

Merci pour vos réponses.

Etant dans un contexte de maintenance, il est difficile de tout chambouler. L'idée de koala01 me semble la plus simple et la plus adaptée.
Et après réflexion, je pense que c'est une solution générale qui peut s'appliquer dans de nombreux contextes: confier à la classe de base l'essentiel des accès extérieurs.

Encore merci.

Il faut quand même avouer que, si ma solution est valide et "correcte" (dans le sens où elle permet de faire ce que tu recherche), elle n'est malgré tout qu'un "pis allez" te permettant de résoudre un problème de conception à la base, car les réflexions à avoir sont:

La (les) fonctions que tu t'apprête à rajouter à la classe de base sont, certes, utiles, mais sont-elles opportunes dans la classe de base

D'une manière ou d'une autre, les fonctions rajoutées à la classe de base devront "communiquer" avec la classe dans laquelle tu déclare l'amitié.

Cela implique, au minimum de passer cette classe par argument à la (aux) fonction(s) membre(s) rajoutée(s), au maximum de prévoir une composition ou une agrégation de cette classe dans la classe de base... Mais est-ce opportun