Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Heritage d'une classe...

Heritage d'une classe...

25 réponses
Avatar
Adrien Constant
Ou ne sait quel nom cela porte, mais considérant l'exemple suivant :

#include <stdio.h>

class Bla
{
public:
int x;
class T;
};

class Bla::T : public Bla
{
public:
int h;
void aff(){printf("%d %d\n", x, h);}
};

int main()
{
Bla *bla = new Bla;
bla->x = 5;
Bla::T *t = new Bla::T;
t->h = 7;
t->aff();
}

Cela affiche évidemment x=undef=0 et h=7, hors comment faire pour que
l'objet qui a créé la class Bla soit utilité pour créer celui de la
classe Bla::T et qu'on obtienne x=5 et h=7 ?

Merci.

Adrien Constant
Signaler un problème avec ce contenu

5 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Adrien Constant
Laurent DELEPINE wrote:
Adrien Constant wrote:

Non un client n'est pas un serveur (c'est meme plutot son contraire..)
mais le client n'existe pas sans le serveur. C'est pour ca que je veux
que l'object class Client ne soit crée que par class Serveur. Et c'est
justement parceque un seul serveur doit gérer plusieurs clients que
je veux pouvoir créer le nbre que je souhaite de chacun.

Meme dans le cas ou ce serait "mieux" de faire deux classes séparées,
je voudrais quand meme des exemples de class qui comportent des
classes, et essayer de trouver ce que j'essaie de faire sans succès
depuis qq heures..



J'ai probleme de comprehension. Tu crées un programme client/serveur
avec communication par reseau. Dans ce cas, les instances de classes
peuvent se trouver sur deux ordinateur differents. C'est ca ?

A+

LD




Oui il est vrai. Pour l'instant c'est juste le début du serveur, comme
je débute en C++ c'est juste pour donner une idée de ce à quoi ça va
ressembler. Mais il faudra aussi développer le client, sauf que ce ne
seront surement pas du tout les memes classes... les variables du
serveur sont en gros sont fd, des sets de fds pour select(), ds buffer
et des struct sockaddr, la moitié de tt ca le client n'en aura aucune
utilité.


Avatar
kanze
"Christophe Lephay" wrote in message
news:<bmk0m0$61m$...
wrote:
Je ne vois pas ce qu'il y a de tordu a avoir une classe dans une
classe et vouloir en hériter.


Ce n'est pas ce qu'il y a de plus fréquent, mais il y a
effectivement des cas où ça peu servir. Mais pas pour ce que tu
sembles vouloir faire.


Tu penses à quoi, en l'occurence ? (simple curiosité)


Rien en particulier. Simplement que même si c'est rare, il peut y avoir
des cas où la classe imbriquée hérite de la classe qui le contient.

Un exemple possible serait un variant sur la combinaison d'un singleton
et de l'idiome du « compilation firewall » que j'utilise de temps en
temps :

class SomeSingleton
{
class Impl ;
public:
static SomeSingleton& instance() ;
virtual void functionA() = 0 ;
// ...
} ;

et dans le fichier de l'implémentation :

class SomeSingleton::Impl
{
public:
virtual void functionA() ;
// ...
} ;

SomeSingleton&
SomeSingleton::instance()
{
static SomeSingleton::Impl
theOneAndOnly ;
return theOneAndOnly ;
}

J'imagine qu'il peut y avoir d'autres cas aussi ; des envéloppe/lettre
où les implémentations sont connues et figées dès le départ, par
exemple.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16



Avatar
kanze
Adrien Constant wrote in message
news:<3f8db30d$0$20647$...

Non un client n'est pas un serveur (c'est meme plutot son contraire..)
mais le client n'existe pas sans le serveur. C'est pour ca que je veux
que l'object class Client ne soit crée que par class Serveur. Et c'est
justement parceque un seul serveur doit gérer plusieurs clients que je
veux pouvoir créer le nbre que je souhaite de chacun.


class Client
{
public:
// ...

private:
friend class Server ;
Client( Server& owner ) : myOwner( owner )
{
// ...
}

Server& myOwner ;
} ;

class Server
{
public:
// ...
Client* createClient()
{
return new Client( this ) ;
}
} /

Meme dans le cas ou ce serait "mieux" de faire deux classes séparées,
je voudrais quand meme des exemples de class qui comportent des
classes, et essayer de trouver ce que j'essaie de faire sans succès
depuis qq heures..


Logiquement, ici, je verrais deux classes indépendantes, avec Server
comme ami de Client. Mais en général, ça marcherait aussi bien si Client
était une classe imbriquée dans Server.

Néanmoins, j'aurais des hésitations à faire comme ceci. Après tout, il
suffit que Client prend un Server& pour que l'utilisateur soit obligé à
l'associer à un Server. Et qui sait -- peut-être dans le temps, tu
finiras par avoir plusieurs types de Client, que Client elle-même
devient une classe abstraite, et que divers utilisateurs finissent par
fournir leurs propres classes dérivées.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Avatar
Christophe Lephay
wrote:
"Christophe Lephay" wrote in message
news:<bmk0m0$61m$...
wrote:
Je ne vois pas ce qu'il y a de tordu a avoir une classe dans une
classe et vouloir en hériter.


Ce n'est pas ce qu'il y a de plus fréquent, mais il y a
effectivement des cas où ça peu servir. Mais pas pour ce que tu
sembles vouloir faire.


Tu penses à quoi, en l'occurence ? (simple curiosité)


Un exemple possible serait un variant sur la combinaison d'un
singleton et de l'idiome du « compilation firewall » que j'utilise de
temps en temps :
...

J'imagine qu'il peut y avoir d'autres cas aussi ; des envéloppe/lettre
où les implémentations sont connues et figées dès le départ, par
exemple.


Ce dont parlait le posteur initial, c'était un truc genre :

class A
{
class B : public A { ... };
};

Chris




Avatar
Adrien Constant
wrote:
Adrien Constant wrote in message
news:<3f8db30d$0$20647$...


Non un client n'est pas un serveur (c'est meme plutot son contraire..)
mais le client n'existe pas sans le serveur. C'est pour ca que je veux
que l'object class Client ne soit crée que par class Serveur. Et c'est
justement parceque un seul serveur doit gérer plusieurs clients que je
veux pouvoir créer le nbre que je souhaite de chacun.



class Client
{
public:
// ...

private:
friend class Server ;
Client( Server& owner ) : myOwner( owner )
{
// ...
}

Server& myOwner ;
} ;

class Server
{
public:
// ...
Client* createClient()
{
return new Client( this ) ;
}
} /



Oui c'est comme ça que je me suis résigné à faire... apparemment la
manière que j'avais de penser à la création d'un objet (qui se referrait
à Perl) n'a pas l'air d'exister en C++, donc j'ai fais deux classes
Client et Serveur distinctes et copines.


Meme dans le cas ou ce serait "mieux" de faire deux classes séparées,
je voudrais quand meme des exemples de class qui comportent des
classes, et essayer de trouver ce que j'essaie de faire sans succès
depuis qq heures..



Logiquement, ici, je verrais deux classes indépendantes, avec Server
comme ami de Client. Mais en général, ça marcherait aussi bien si Client
était une classe imbriquée dans Server.


Ca marchait aussi, je voulais juste éviter de passer en paramètre une
référence à un objet Server qui existait dejà. Je pensais que dans le
cas de classes imbriquées, une classe "fille" pouvait connaitre
l'adresse de son parent (comme this pour la classe meme).


Néanmoins, j'aurais des hésitations à faire comme ceci. Après tout, il
suffit que Client prend un Server& pour que l'utilisateur soit obligé à
l'associer à un Server. Et qui sait -- peut-être dans le temps, tu
finiras par avoir plusieurs types de Client, que Client elle-même
devient une classe abstraite, et que divers utilisateurs finissent par
fournir leurs propres classes dérivées.


C'est vrai, mais si Client prend Server&, l'objet Server retourné n'aura
pas forcément les bons paramètres pris en compte (mais les params par
défaut). Ce que je vais peut etre faire en fin de compte c'est faire que
la création d'un Serveur crée n objets Client, puisque c'est en fait un
peu ce que je fais en deux étapes.


--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16



1 2 3