Voilà.. si qq'un arrive à me comprendre ce me serait vraiment très très
utile de savoir :)
Voilà.. si qq'un arrive à me comprendre ce me serait vraiment très très
utile de savoir :)
Voilà.. si qq'un arrive à me comprendre ce me serait vraiment très très
utile de savoir :)
class Bla
{
public:
int x;
class T;
};
class Bla::T : public Bla
{
public:
int h;
void aff(){printf("%d %dn", 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 ?
class Bla
{
public:
int x;
class T;
};
class Bla::T : public Bla
{
public:
int h;
void aff(){printf("%d %dn", 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 ?
class Bla
{
public:
int x;
class T;
};
class Bla::T : public Bla
{
public:
int h;
void aff(){printf("%d %dn", 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 ?
Non ce n'est pas tordu cela est courant dans certains langages.
struct T {};
struct Bla { struct T *t; };
Et bien je veux faire pareil avec des classes tout en ayant T qui
puisse accéder aux méthodes / variables publiques de Bla.
C'est évidemment possible de passer par une référence de Bla mais je
pense qu'il est possible de faire autrement, puisque c'est a ca que
sert l'héritage ai-je cru comprendre.
L'intéret n'est autre que pour la clareté du code, le plus simple est
effectivement de faire deux classes séparées. Je ne vois pas ce qu'il
y a de tordu a avoir une classe dans une classe et vouloir en hériter.
class Bla {
public:
int x, y, z;
int *fd_list;
}
On peut tout simplement avoir besoin d'une classe spéciale au lieu
d'utiliser int *fd_list dans que cas on peut créer
class FdList {
public:
FdList();
~FdList();
Add(int fd);
Remove(int fd);
int *fd_list;
}
et décider de faire new Bla::FdList[15];
Non ce n'est pas tordu cela est courant dans certains langages.
struct T {};
struct Bla { struct T *t; };
Et bien je veux faire pareil avec des classes tout en ayant T qui
puisse accéder aux méthodes / variables publiques de Bla.
C'est évidemment possible de passer par une référence de Bla mais je
pense qu'il est possible de faire autrement, puisque c'est a ca que
sert l'héritage ai-je cru comprendre.
L'intéret n'est autre que pour la clareté du code, le plus simple est
effectivement de faire deux classes séparées. Je ne vois pas ce qu'il
y a de tordu a avoir une classe dans une classe et vouloir en hériter.
class Bla {
public:
int x, y, z;
int *fd_list;
}
On peut tout simplement avoir besoin d'une classe spéciale au lieu
d'utiliser int *fd_list dans que cas on peut créer
class FdList {
public:
FdList();
~FdList();
Add(int fd);
Remove(int fd);
int *fd_list;
}
et décider de faire new Bla::FdList[15];
Non ce n'est pas tordu cela est courant dans certains langages.
struct T {};
struct Bla { struct T *t; };
Et bien je veux faire pareil avec des classes tout en ayant T qui
puisse accéder aux méthodes / variables publiques de Bla.
C'est évidemment possible de passer par une référence de Bla mais je
pense qu'il est possible de faire autrement, puisque c'est a ca que
sert l'héritage ai-je cru comprendre.
L'intéret n'est autre que pour la clareté du code, le plus simple est
effectivement de faire deux classes séparées. Je ne vois pas ce qu'il
y a de tordu a avoir une classe dans une classe et vouloir en hériter.
class Bla {
public:
int x, y, z;
int *fd_list;
}
On peut tout simplement avoir besoin d'une classe spéciale au lieu
d'utiliser int *fd_list dans que cas on peut créer
class FdList {
public:
FdList();
~FdList();
Add(int fd);
Remove(int fd);
int *fd_list;
}
et décider de faire new Bla::FdList[15];
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.
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.
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.
Adrien Constant wrote:class Bla
{
public:
int x;
class T;
};
class Bla::T : public Bla
{
public:
int h;
void aff(){printf("%d %dn", 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 ?
Ton problème, c'est que tu as deux objets Bla créés : un avec ton ne Bla, et
l'autre avec ton new Bla::T (qui crée bien un Bla par héritage).
Ce que tu veux faire n'est pas clair : veux-tu la création de deux objets
(auquel cas il est normal que les deux objets aient des x différents) ou un
seul (auquel cas soit l'héritage est une erreur de conception, soit il ne
faut pas créer d'objet Bla).
Si tu veux qu'un "sous-objet" garde une référence sur un autre, l'héritage
est une erreur :
class Bla {
int x;
public:
class T {
int h;
Bla * parent;
public:
T( const Bla& un_bla ) : parent( &un_bla ) {}
};
};
De cette manière, la référence au parent est fournie lors de la construction
de l'objet T (attention si les durées de vie des deux objets diffèrent).
Si tu veux que le "sous-objet" crée une copie d'un objet parent, alors tu
peux utiliser l'héritage, mais il faut toujours fournir le parent au
constructeur :
class Bla {
int x;
public:
class T : public Bla {
int h;
public:
T( const Bla& un_bla ) : Bla( un_bla ) {} // il faut un cteur-copieur
dans Bla
};
};
Si les deux objets (Bla et T::Bla) sont forcément liés, il est alors plus
avisé de faire en sorte que le "parent" connaisse l'enfant, de manière à le
détruire lorsque lui-même est détruit.
Bref, l'objectif que tu poursuis n'est pas du tout clair, essaie de
réfléchir un peu plus précisément à ce que tu veux faire, avant de penser à
comment tu veux le faire...
Chris
class Bla {
int x;
public:
class T {
int h;
Bla * parent;
public:
T( const Bla& un_bla ) : parent( &un_bla ) {}
};
};
Adrien Constant wrote:
class Bla
{
public:
int x;
class T;
};
class Bla::T : public Bla
{
public:
int h;
void aff(){printf("%d %dn", 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 ?
Ton problème, c'est que tu as deux objets Bla créés : un avec ton ne Bla, et
l'autre avec ton new Bla::T (qui crée bien un Bla par héritage).
Ce que tu veux faire n'est pas clair : veux-tu la création de deux objets
(auquel cas il est normal que les deux objets aient des x différents) ou un
seul (auquel cas soit l'héritage est une erreur de conception, soit il ne
faut pas créer d'objet Bla).
Si tu veux qu'un "sous-objet" garde une référence sur un autre, l'héritage
est une erreur :
class Bla {
int x;
public:
class T {
int h;
Bla * parent;
public:
T( const Bla& un_bla ) : parent( &un_bla ) {}
};
};
De cette manière, la référence au parent est fournie lors de la construction
de l'objet T (attention si les durées de vie des deux objets diffèrent).
Si tu veux que le "sous-objet" crée une copie d'un objet parent, alors tu
peux utiliser l'héritage, mais il faut toujours fournir le parent au
constructeur :
class Bla {
int x;
public:
class T : public Bla {
int h;
public:
T( const Bla& un_bla ) : Bla( un_bla ) {} // il faut un cteur-copieur
dans Bla
};
};
Si les deux objets (Bla et T::Bla) sont forcément liés, il est alors plus
avisé de faire en sorte que le "parent" connaisse l'enfant, de manière à le
détruire lorsque lui-même est détruit.
Bref, l'objectif que tu poursuis n'est pas du tout clair, essaie de
réfléchir un peu plus précisément à ce que tu veux faire, avant de penser à
comment tu veux le faire...
Chris
class Bla {
int x;
public:
class T {
int h;
Bla * parent;
public:
T( const Bla& un_bla ) : parent( &un_bla ) {}
};
};
Adrien Constant wrote:class Bla
{
public:
int x;
class T;
};
class Bla::T : public Bla
{
public:
int h;
void aff(){printf("%d %dn", 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 ?
Ton problème, c'est que tu as deux objets Bla créés : un avec ton ne Bla, et
l'autre avec ton new Bla::T (qui crée bien un Bla par héritage).
Ce que tu veux faire n'est pas clair : veux-tu la création de deux objets
(auquel cas il est normal que les deux objets aient des x différents) ou un
seul (auquel cas soit l'héritage est une erreur de conception, soit il ne
faut pas créer d'objet Bla).
Si tu veux qu'un "sous-objet" garde une référence sur un autre, l'héritage
est une erreur :
class Bla {
int x;
public:
class T {
int h;
Bla * parent;
public:
T( const Bla& un_bla ) : parent( &un_bla ) {}
};
};
De cette manière, la référence au parent est fournie lors de la construction
de l'objet T (attention si les durées de vie des deux objets diffèrent).
Si tu veux que le "sous-objet" crée une copie d'un objet parent, alors tu
peux utiliser l'héritage, mais il faut toujours fournir le parent au
constructeur :
class Bla {
int x;
public:
class T : public Bla {
int h;
public:
T( const Bla& un_bla ) : Bla( un_bla ) {} // il faut un cteur-copieur
dans Bla
};
};
Si les deux objets (Bla et T::Bla) sont forcément liés, il est alors plus
avisé de faire en sorte que le "parent" connaisse l'enfant, de manière à le
détruire lorsque lui-même est détruit.
Bref, l'objectif que tu poursuis n'est pas du tout clair, essaie de
réfléchir un peu plus précisément à ce que tu veux faire, avant de penser à
comment tu veux le faire...
Chris
class Bla {
int x;
public:
class T {
int h;
Bla * parent;
public:
T( const Bla& un_bla ) : parent( &un_bla ) {}
};
};
Voilà je pense qu'en gros c'est ça, sauf que comme je l'avais marqué
dans une de mes réponse je voulais savoir si il est possible de le
faire _sans_ passer une référence de la classe parent. Etant donné
que la
class T fait partie de la classe Bla je pensais qu'il était possible
qu'il soit assigné à Bla::T un parent lors de la construction de
l'objet. Un syntaxe qui n'existe pas en C++ mais qui aurait pu etre
du genre:
Bla *bla = new Bla[10]; // 10 classes Bla, normal
Bla::T *t = new Bla::T bla[5]->T[3];
// 3 classes Bla::T crées à partir du 5e élément de *bla
Je sais c'est absurde en tout cas en C++ mais c'est pour essayer de
faire comprendre ce que je souhaiterais faire.
En fait dans mon cas précis ca ressemble à ca :
class Server
{
public:
[...]
int fd_sock;
class Client
{
public:
int fd_client;
// blabla
};
};
hors, la class Client a besoin d'accéder aux variables de Server.
On crée un (ou plusieurs serveurs)
Server *server = new Server;
Puis dans le cas ou on voudrait avoir SOMAXCONN max clients :
Server::Client *clients = new Server::Client[SOMAXCONN];
Donc en sachant que les clients doivent avoir accès à Server::fd_sock
et autres variables / fonctions publiques de Server, et que Server
devrait avoir accès aux variables / fctions publiques de
Server::Client. En fait ca revient strictement au meme que d'avoir
une seule classe :
class Server
{
public:
int fd_sock;
int *fd_client; // ici du coup on aura besoin d'un tableau
[...]
};
et de faire
Server *server = new Server;
server->fd_client = new int[SOMAXCONN];
sauf que vous l'aurez compris, pour des soucis de logique de code et
surtout pour simplifier les choses (il faut chaque fois créer des
tableaux 2d il est bcp plus simple d'allouer n classes et d'accéder
directement à l'élément n, sinon avec beaucoup de variables et de
fonctions ca peut devenir assez bordélique) je préfère avoir une class
Server et une class Client séparés.
On pourrait également faire
class Server {};
class Client {};
Mais vu que la class Client n'a aucune raison d'exister seule (il lui
faut un père) je ne trouve pas ça très logique de la séparer de son
parant.
Voilà je pense qu'en gros c'est ça, sauf que comme je l'avais marqué
dans une de mes réponse je voulais savoir si il est possible de le
faire _sans_ passer une référence de la classe parent. Etant donné
que la
class T fait partie de la classe Bla je pensais qu'il était possible
qu'il soit assigné à Bla::T un parent lors de la construction de
l'objet. Un syntaxe qui n'existe pas en C++ mais qui aurait pu etre
du genre:
Bla *bla = new Bla[10]; // 10 classes Bla, normal
Bla::T *t = new Bla::T bla[5]->T[3];
// 3 classes Bla::T crées à partir du 5e élément de *bla
Je sais c'est absurde en tout cas en C++ mais c'est pour essayer de
faire comprendre ce que je souhaiterais faire.
En fait dans mon cas précis ca ressemble à ca :
class Server
{
public:
[...]
int fd_sock;
class Client
{
public:
int fd_client;
// blabla
};
};
hors, la class Client a besoin d'accéder aux variables de Server.
On crée un (ou plusieurs serveurs)
Server *server = new Server;
Puis dans le cas ou on voudrait avoir SOMAXCONN max clients :
Server::Client *clients = new Server::Client[SOMAXCONN];
Donc en sachant que les clients doivent avoir accès à Server::fd_sock
et autres variables / fonctions publiques de Server, et que Server
devrait avoir accès aux variables / fctions publiques de
Server::Client. En fait ca revient strictement au meme que d'avoir
une seule classe :
class Server
{
public:
int fd_sock;
int *fd_client; // ici du coup on aura besoin d'un tableau
[...]
};
et de faire
Server *server = new Server;
server->fd_client = new int[SOMAXCONN];
sauf que vous l'aurez compris, pour des soucis de logique de code et
surtout pour simplifier les choses (il faut chaque fois créer des
tableaux 2d il est bcp plus simple d'allouer n classes et d'accéder
directement à l'élément n, sinon avec beaucoup de variables et de
fonctions ca peut devenir assez bordélique) je préfère avoir une class
Server et une class Client séparés.
On pourrait également faire
class Server {};
class Client {};
Mais vu que la class Client n'a aucune raison d'exister seule (il lui
faut un père) je ne trouve pas ça très logique de la séparer de son
parant.
Voilà je pense qu'en gros c'est ça, sauf que comme je l'avais marqué
dans une de mes réponse je voulais savoir si il est possible de le
faire _sans_ passer une référence de la classe parent. Etant donné
que la
class T fait partie de la classe Bla je pensais qu'il était possible
qu'il soit assigné à Bla::T un parent lors de la construction de
l'objet. Un syntaxe qui n'existe pas en C++ mais qui aurait pu etre
du genre:
Bla *bla = new Bla[10]; // 10 classes Bla, normal
Bla::T *t = new Bla::T bla[5]->T[3];
// 3 classes Bla::T crées à partir du 5e élément de *bla
Je sais c'est absurde en tout cas en C++ mais c'est pour essayer de
faire comprendre ce que je souhaiterais faire.
En fait dans mon cas précis ca ressemble à ca :
class Server
{
public:
[...]
int fd_sock;
class Client
{
public:
int fd_client;
// blabla
};
};
hors, la class Client a besoin d'accéder aux variables de Server.
On crée un (ou plusieurs serveurs)
Server *server = new Server;
Puis dans le cas ou on voudrait avoir SOMAXCONN max clients :
Server::Client *clients = new Server::Client[SOMAXCONN];
Donc en sachant que les clients doivent avoir accès à Server::fd_sock
et autres variables / fonctions publiques de Server, et que Server
devrait avoir accès aux variables / fctions publiques de
Server::Client. En fait ca revient strictement au meme que d'avoir
une seule classe :
class Server
{
public:
int fd_sock;
int *fd_client; // ici du coup on aura besoin d'un tableau
[...]
};
et de faire
Server *server = new Server;
server->fd_client = new int[SOMAXCONN];
sauf que vous l'aurez compris, pour des soucis de logique de code et
surtout pour simplifier les choses (il faut chaque fois créer des
tableaux 2d il est bcp plus simple d'allouer n classes et d'accéder
directement à l'élément n, sinon avec beaucoup de variables et de
fonctions ca peut devenir assez bordélique) je préfère avoir une class
Server et une class Client séparés.
On pourrait également faire
class Server {};
class Client {};
Mais vu que la class Client n'a aucune raison d'exister seule (il lui
faut un père) je ne trouve pas ça très logique de la séparer de son
parant.
Si c'est une relation 1-1, alors l'héritage suffit.
Avec :
class Bla
{
public:
int x;
};
class T : public Bla
{
public:
int h;
};
en créant un objet de type T, un objet de type Bla est automatiquement créé
:
T objet;
objet.x = 5; objet.h = 10;
Bla *bla = new Bla[10]; // 10 classes Bla, normal
Bla::T *t = new Bla::T bla[5]->T[3];
// 3 classes Bla::T crées à partir du 5e élément de *bla
Je sais c'est absurde en tout cas en C++ mais c'est pour essayer de
faire comprendre ce que je souhaiterais faire.
Ben c'est encore raté lol
En fait dans mon cas précis ca ressemble à ca :
class Server
{
public:
[...]
int fd_sock;
class Client
{
public:
int fd_client;
// blabla
};
};
C'est une erreur d'analyse de faire hériter client de serveur. Pour
reprendre l'explication de James, un client *n'est pas* un serveur. De plus,
un même serveur va gérer plusieurs clients. En fait, la classe serveur doit
gérer une liste de connections clientes, et c'est une relation
d'appartenance, pas une relation "est un".
A toi de voir si la classe client doit être accessible de l'extérieur ou
non...
Chris
Si c'est une relation 1-1, alors l'héritage suffit.
Avec :
class Bla
{
public:
int x;
};
class T : public Bla
{
public:
int h;
};
en créant un objet de type T, un objet de type Bla est automatiquement créé
:
T objet;
objet.x = 5; objet.h = 10;
Bla *bla = new Bla[10]; // 10 classes Bla, normal
Bla::T *t = new Bla::T bla[5]->T[3];
// 3 classes Bla::T crées à partir du 5e élément de *bla
Je sais c'est absurde en tout cas en C++ mais c'est pour essayer de
faire comprendre ce que je souhaiterais faire.
Ben c'est encore raté lol
En fait dans mon cas précis ca ressemble à ca :
class Server
{
public:
[...]
int fd_sock;
class Client
{
public:
int fd_client;
// blabla
};
};
C'est une erreur d'analyse de faire hériter client de serveur. Pour
reprendre l'explication de James, un client *n'est pas* un serveur. De plus,
un même serveur va gérer plusieurs clients. En fait, la classe serveur doit
gérer une liste de connections clientes, et c'est une relation
d'appartenance, pas une relation "est un".
A toi de voir si la classe client doit être accessible de l'extérieur ou
non...
Chris
Si c'est une relation 1-1, alors l'héritage suffit.
Avec :
class Bla
{
public:
int x;
};
class T : public Bla
{
public:
int h;
};
en créant un objet de type T, un objet de type Bla est automatiquement créé
:
T objet;
objet.x = 5; objet.h = 10;
Bla *bla = new Bla[10]; // 10 classes Bla, normal
Bla::T *t = new Bla::T bla[5]->T[3];
// 3 classes Bla::T crées à partir du 5e élément de *bla
Je sais c'est absurde en tout cas en C++ mais c'est pour essayer de
faire comprendre ce que je souhaiterais faire.
Ben c'est encore raté lol
En fait dans mon cas précis ca ressemble à ca :
class Server
{
public:
[...]
int fd_sock;
class Client
{
public:
int fd_client;
// blabla
};
};
C'est une erreur d'analyse de faire hériter client de serveur. Pour
reprendre l'explication de James, un client *n'est pas* un serveur. De plus,
un même serveur va gérer plusieurs clients. En fait, la classe serveur doit
gérer une liste de connections clientes, et c'est une relation
d'appartenance, pas une relation "est un".
A toi de voir si la classe client doit être accessible de l'extérieur ou
non...
Chris
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..
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..
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..
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.
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.
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.
