j'ai plusieurs threads qui tournent. chaque thread est un objet. dans
le programme principal, j'ai une liste de tous ces threads (dans un
tableau par exemple).
supposons qu'un thread se termine. comment peut-il prevenir le
programme principal, afin qu'il enleve sa reference de la liste de
threads ?
solution 1 (mauvaise) : le thread a une reference vers la liste, et il
peut la modifier. or, cela est absurde en programmation objet; le
thread (qui est un objet) n'a pas a contenir une reference vers la
liste.
solution 2 (mauvaise) : la liste est une variable globale. le thread
peut donc y avoir acces. or, une fois de plus, cela est absurde en
programmation objet; le thread n'a pas a s'occuper de mettre la liste
de threads a jour. il n'est meme pas cense savoir qu'il est repertorie
dans une liste.
existe-t-il une solution propre et non-marginale a ce probleme de
conception objet ?
"Franck Guillaud" a écrit dans le message de news: 41e40c61$0$7887$
J'invite les contributeurs de ce thread à consulter l'URL suivante :
http://lucii.free.fr/
Vous en saurez alors un peu plus sur la nature du personnage. Après, libre à vous de continuer à tenter d'argumenter.
Oui, j'en ai personnellement terminé avec lui ;)
luc2
On Tue, 11 Jan 2005 17:39:43 +0100, "Christophe Lephay" wrote:
les observeurs sont classiques dans la programmation orientee objet en general, mais en pratique, presqu'aucun programme en c++ ne les utilise. c'est un fait.
Oui, et c'est même un fait tout droit sorti de ton chapeau, pour être plus précis.
dis-moi quel pourcentage de programmes c++ contiennent des observeurs ?
On Tue, 11 Jan 2005 17:39:43 +0100, "Christophe Lephay"
<christophe-lephay@wanadoo.fr> wrote:
les observeurs sont classiques dans la programmation orientee objet en
general, mais en pratique, presqu'aucun programme en c++ ne les
utilise. c'est un fait.
Oui, et c'est même un fait tout droit sorti de ton chapeau, pour être plus
précis.
dis-moi quel pourcentage de programmes c++ contiennent des observeurs
?
On Tue, 11 Jan 2005 17:39:43 +0100, "Christophe Lephay" wrote:
les observeurs sont classiques dans la programmation orientee objet en general, mais en pratique, presqu'aucun programme en c++ ne les utilise. c'est un fait.
Oui, et c'est même un fait tout droit sorti de ton chapeau, pour être plus précis.
dis-moi quel pourcentage de programmes c++ contiennent des observeurs ?
Fabien Garcia
Le Tue, 11 Jan 2005 17:32:39 +0100, luc2 a écrit:
On Tue, 11 Jan 2005 16:10:56 +0100, "Christophe Lephay" wrote:
[SNIP]
vraiment ? ca vous semble coherent a vous qu'un objet contienne une liste de lui-meme ?
Oui, si la conception d'une application utilisant cet objet le necessite.
un bouton doit forcement contenir une liste de boutons ? une fenetre doit forcement contenir une liste de fenetres ? un thread doit forcement contenir une liste de threads ?
Non, mais un thread_observe (ce que tu semble demander) peut heriter de la clase thread et utiliser une liste de lui meme. Tu ne semble pas vouloir un thread mais un thread qui a un comportement specifique, defini donc un objet qui a ce comportement.
moi je pense que vous voyez TRES BIEN que ce n'est pas coherent, et que ma vision de la conception objet n'a rien de personnel.
TU penses
vous en avez deja suffisamment pour raisonner : un objet faisant partie d'une liste n'a pas a contenir la liste elle-meme.
Sauf s'il doit appeler une methode de la liste, ce qui dans ton cas ne peut etre evite que par un objet qui gererait la liste.
PS : cet avis n'est pas celui d'un pros du C++, ni celui d'un inquisiteur de la POO, donc inutile de te fatiguer a essayer de prouver que tu es plus intelligent, c'est surement le cas.
Le Tue, 11 Jan 2005 17:32:39 +0100, luc2 <luc2@nospam.invalid> a écrit:
On Tue, 11 Jan 2005 16:10:56 +0100, "Christophe Lephay"
<christophe-lephay@wanadoo.fr> wrote:
[SNIP]
vraiment ? ca vous semble coherent a vous qu'un objet contienne une
liste de lui-meme ?
Oui, si la conception d'une application utilisant cet objet le necessite.
un bouton doit forcement contenir une liste de
boutons ? une fenetre doit forcement contenir une liste de fenetres ?
un thread doit forcement contenir une liste de threads ?
Non, mais un thread_observe (ce que tu semble demander) peut heriter de la
clase thread
et utiliser une liste de lui meme. Tu ne semble pas vouloir un thread mais
un thread qui a un comportement specifique, defini donc un objet qui a ce
comportement.
moi je pense que vous voyez TRES BIEN que ce n'est pas coherent, et
que ma vision de la conception objet n'a rien de personnel.
TU penses
vous en avez deja suffisamment pour raisonner : un objet faisant
partie d'une liste n'a pas a contenir la liste elle-meme.
Sauf s'il doit appeler une methode de la liste, ce qui dans ton cas ne
peut etre evite que par un objet qui gererait la liste.
PS : cet avis n'est pas celui d'un pros du C++, ni celui d'un inquisiteur
de la POO, donc inutile de te fatiguer a essayer de prouver que tu es plus
intelligent, c'est surement le cas.
On Tue, 11 Jan 2005 16:10:56 +0100, "Christophe Lephay" wrote:
[SNIP]
vraiment ? ca vous semble coherent a vous qu'un objet contienne une liste de lui-meme ?
Oui, si la conception d'une application utilisant cet objet le necessite.
un bouton doit forcement contenir une liste de boutons ? une fenetre doit forcement contenir une liste de fenetres ? un thread doit forcement contenir une liste de threads ?
Non, mais un thread_observe (ce que tu semble demander) peut heriter de la clase thread et utiliser une liste de lui meme. Tu ne semble pas vouloir un thread mais un thread qui a un comportement specifique, defini donc un objet qui a ce comportement.
moi je pense que vous voyez TRES BIEN que ce n'est pas coherent, et que ma vision de la conception objet n'a rien de personnel.
TU penses
vous en avez deja suffisamment pour raisonner : un objet faisant partie d'une liste n'a pas a contenir la liste elle-meme.
Sauf s'il doit appeler une methode de la liste, ce qui dans ton cas ne peut etre evite que par un objet qui gererait la liste.
PS : cet avis n'est pas celui d'un pros du C++, ni celui d'un inquisiteur de la POO, donc inutile de te fatiguer a essayer de prouver que tu es plus intelligent, c'est surement le cas.
Vincent Lascaux
dis-moi quel pourcentage de programmes c++ contiennent des observeurs ?
Je dirais environ entre 67,81% et 83,11%
Pourquoi tu as besoin de savoir ca ? On te propose un design pattern, c'est donc un truc qui est reconnu comme bon quelque soit le langage orienté objet si on est dans ses conditions d'utilisation. Point final.
-- Vincent
dis-moi quel pourcentage de programmes c++ contiennent des observeurs
?
Je dirais environ entre 67,81% et 83,11%
Pourquoi tu as besoin de savoir ca ? On te propose un design pattern, c'est
donc un truc qui est reconnu comme bon quelque soit le langage orienté objet
si on est dans ses conditions d'utilisation. Point final.
dis-moi quel pourcentage de programmes c++ contiennent des observeurs ?
Je dirais environ entre 67,81% et 83,11%
Pourquoi tu as besoin de savoir ca ? On te propose un design pattern, c'est donc un truc qui est reconnu comme bon quelque soit le langage orienté objet si on est dans ses conditions d'utilisation. Point final.
-- Vincent
PurL
mais le mot "courante" de l'enonce voulait dire "courante EN GENERAL".
Moi je vois qu'une seule chose : c'est que l'énoncé est stupide !
De plus, a partir de quoi quelque chose est courant ou ne l'est pas ? C'est vraiment tres subjectif...
A partir du moment où c'est supporté par le langage, c'est qu'on peut l'utiliser ! Commence par le faire, dit à tes copains de faire pareil et dans un an, ca sera courant de la faire...
PurL
mais le mot "courante" de l'enonce voulait dire "courante EN GENERAL".
Moi je vois qu'une seule chose : c'est que l'énoncé est stupide !
De plus, a partir de quoi quelque chose est courant ou ne l'est pas ?
C'est vraiment tres subjectif...
A partir du moment où c'est supporté par le langage, c'est qu'on peut
l'utiliser !
Commence par le faire, dit à tes copains de faire pareil et dans un an, ca
sera courant de la faire...
mais le mot "courante" de l'enonce voulait dire "courante EN GENERAL".
Moi je vois qu'une seule chose : c'est que l'énoncé est stupide !
De plus, a partir de quoi quelque chose est courant ou ne l'est pas ? C'est vraiment tres subjectif...
A partir du moment où c'est supporté par le langage, c'est qu'on peut l'utiliser ! Commence par le faire, dit à tes copains de faire pareil et dans un an, ca sera courant de la faire...
PurL
Christophe Lephay
"Vincent Lascaux" a écrit dans le message de news: 41e40fde$0$10252$
Pourquoi tu as besoin de savoir ca ? On te propose un design pattern, c'est donc un truc qui est reconnu comme bon quelque soit le langage orienté objet si on est dans ses conditions d'utilisation. Point final.
Mais il y a un problème dans ce que tu dis. Si on part du postulat qu'on ne peut coder proprement ni véritablement en OO en C++, alors un pattern "propre" et OO ne peut être applicable au C++. Où alors il est nécessaire d'insister sur son caractère exceptionnel.
Bien sur, on peut aussi remettre en question ce postulat implicite du posteur initial, mais je ne crois pas que celà soit soit son but dans cette discussion ;)
"Vincent Lascaux" <nospam@nospam.org> a écrit dans le message de news:
41e40fde$0$10252$626a14ce@news.free.fr...
Pourquoi tu as besoin de savoir ca ? On te propose un design pattern,
c'est donc un truc qui est reconnu comme bon quelque soit le langage
orienté objet si on est dans ses conditions d'utilisation. Point final.
Mais il y a un problème dans ce que tu dis. Si on part du postulat qu'on ne
peut coder proprement ni véritablement en OO en C++, alors un pattern
"propre" et OO ne peut être applicable au C++. Où alors il est nécessaire
d'insister sur son caractère exceptionnel.
Bien sur, on peut aussi remettre en question ce postulat implicite du
posteur initial, mais je ne crois pas que celà soit soit son but dans cette
discussion ;)
"Vincent Lascaux" a écrit dans le message de news: 41e40fde$0$10252$
Pourquoi tu as besoin de savoir ca ? On te propose un design pattern, c'est donc un truc qui est reconnu comme bon quelque soit le langage orienté objet si on est dans ses conditions d'utilisation. Point final.
Mais il y a un problème dans ce que tu dis. Si on part du postulat qu'on ne peut coder proprement ni véritablement en OO en C++, alors un pattern "propre" et OO ne peut être applicable au C++. Où alors il est nécessaire d'insister sur son caractère exceptionnel.
Bien sur, on peut aussi remettre en question ce postulat implicite du posteur initial, mais je ne crois pas que celà soit soit son but dans cette discussion ;)
luc2
On Tue, 11 Jan 2005 18:03:25 +0100, "Christophe Lephay" wrote:
Visiblement tu as du mal à raisonner sur les cas généraux. Tous les exemples de listeners que tu cites de Java concernent des domaines qui ne sont pas couverts par le langage C++. La notion d'interface graphique ou de thread n'est pas couverte par le langage C++.
si. pour le bouton, j'ai parle de l'api de microsoft en c++.
L'api windows définie par microsoft, y compris via ses MFC ne font pas partie du langage C++.
et alors ? ils representent une grande partie des programmes en c++. on a besoin d'eux pour pouvoir dire si les listeners sont courants ou pas en c++.
C'est comme si tu écrivais une application Java et pretendait apres coup qu'elle fait partie du standard Java. Qui plus est, même si j'ai plus utilisé les frameworks borland, il me semble bien que microsoft fait un usage intensif du modele observer. C'est le cas, par exemple, du modele document/view qui y est largement répandu.
document/view ? et "view", c'est l'observateur sans doute ? LAISSE-MOI RIRE ! "view" et la representation a l'ecran du document !
Par contre, dès qu'on doit programmer en C++ la gestion d'une interface graphique ou des threads, il n'y a pas de raison que la solution C++ diffère d'une autre utilisée en Java pour adresser le même problème.
et bien en pratique, ca differe mon cher.
C'est toi qui le dit.
c'est un fait. en pratique en c++, presque personne n'utilise d'observateur.
Le fait qu'ils soient plus fréquents en Java qu'en C++ n'est vrai que tant que tu restreins le langage à des applications *spécifiquement différentes*, ce qui fait que ta généralité ne vaut rien car elle n'est vraie que dans la spécificité des taches auxquelles tu t'attaquerais avec tel ou tel langage.
ah bon ? ma generalisation est specifique ? prouve-le.
Trouve-t-on des listeners dans un programme Java qui ne ferait que compter de 1 à 1000 ? Réponse : non.
Trouve-ton des listeners dans une application graphique C++ ? Réponse : oui.
Ta généralisation n'est donc vraie que tant qu'on confine Java et C++ à des domaines distincts, spécifiques.
j'ai sorti des exemples aussi specifiques que les tiens moi ?
La différence entre C++ et Java, face à la même problématique, c'est que ce pattern fait partie de l'api de Java, tandis qu'il ne fait pas partie de l'api du C++, ce qui laisse le choix de tel design plutôt qu'un autre. Qu'un tel choix existe n'implique aucunement que ce n'est pas un idiome C++.
tu continues a confondre "listeners existants" et "listeners courants". je n'ai jamais dit qu'il etait impossible de faire de listeners en c++. meme si on a le CHOIX d'en faire, en pratique, peu de personnes en font.
Je ne confonds rien du tout. En pratique, tout le monde en utilise dçs lors que le programme gère une interface graphique, qu'il le sache ou non car celà peut très bien être completement encapsulé dans le framework.
si c'est trop bien encapsule, c'est comme s'il n'y en avait pas. en effet, on ne peut pas dire que la solution des listeners est courante, si on ne sait meme pas qu'on l'exploite habituellement.
On est loin du 0% que tu sors de ton chapeau.
dis-moi alors quel est le bon pourcentage te concernant ?
Je ne vais pas à mon tour un nombre sorti de mon chapeau. Par contre, je ne connais pas un seul framework GUI en C++ qui n'utilise pas de listeners. Mais je n'ai pas la prétention de tous les connaitre, et je t'invite à m'en citer qui n'en feraient pas l'usage.
celui de microsoft.
Dans tous les cas, je vais arreter ici ma contribution. Tu as eu les réponses à ta question. Si tu décides de les ignorer car ils iraient à l'encontre de ton a priori, qui te permettraient par exemple d'affirmer à quel point le C++ n'est pas "propre" ou ne permet pas de faire de la POO, je pense que personne ne peut rien pour toi.
Ce ne serait pas la première fois qu'un dogme est établi sur la base d'un autre dogme.
Tu as eu les réponses que tu demandais. Maintenant, tu en fais ce que tu veux.
mais elles ne repondent pas a l'enonce.
Fin de la discussion (en tout cas avec moi).
allez, ne t'en va pas fache. pour me faire pardonner, je vais te donner la solution en c++. je viens de la trouver :
il faut mettre la liste de threads a jour. or, le thread n'a PAS LE DROIT de contenir la liste, puisqu'il ne SAIT PAS qu'il est dans une liste. il suffit donc de creer une classe qui sait qu'elle est dans une liste :
class thread_qui_est_dans_une_liste : thread { thread[] liste; // liste dans laquelle je suis
... }
on utilise ainsi l'HERITAGE. l'heritage est courant, meme en c++. donc, on repond bien a l'enonce.
autre solution :
on peut donner une fonction callback au thread, afin qu'il nous avertisse de sa fin. quand il se termine, il appelle la fonction callback qui s'occupe de mettre la liste a jour.
cette solution ressemble a celle des listeners, sauf qu'on utilise des callbacks. comme les callbacks sont courants en c++, on repond bien a l'enonce.
On Tue, 11 Jan 2005 18:03:25 +0100, "Christophe Lephay"
<christophe-lephay@wanadoo.fr> wrote:
Visiblement tu as du mal à raisonner sur les cas généraux. Tous les
exemples
de listeners que tu cites de Java concernent des domaines qui ne sont pas
couverts par le langage C++. La notion d'interface graphique ou de thread
n'est pas couverte par le langage C++.
si. pour le bouton, j'ai parle de l'api de microsoft en c++.
L'api windows définie par microsoft, y compris via ses MFC ne font pas
partie du langage C++.
et alors ? ils representent une grande partie des programmes en c++.
on a besoin d'eux pour pouvoir dire si les listeners sont courants ou
pas en c++.
C'est comme si tu écrivais une application Java et
pretendait apres coup qu'elle fait partie du standard Java. Qui plus est,
même si j'ai plus utilisé les frameworks borland, il me semble bien que
microsoft fait un usage intensif du modele observer. C'est le cas, par
exemple, du modele document/view qui y est largement répandu.
document/view ? et "view", c'est l'observateur sans doute ? LAISSE-MOI
RIRE ! "view" et la representation a l'ecran du document !
Par contre, dès qu'on doit programmer en C++ la gestion d'une interface
graphique ou des threads, il n'y a pas de raison que la solution C++
diffère
d'une autre utilisée en Java pour adresser le même problème.
et bien en pratique, ca differe mon cher.
C'est toi qui le dit.
c'est un fait. en pratique en c++, presque personne n'utilise
d'observateur.
Le fait qu'ils soient plus fréquents en Java qu'en
C++ n'est vrai que tant que tu restreins le langage à des applications
*spécifiquement différentes*, ce qui fait que ta généralité ne vaut rien
car
elle n'est vraie que dans la spécificité des taches auxquelles tu
t'attaquerais avec tel ou tel langage.
ah bon ? ma generalisation est specifique ? prouve-le.
Trouve-t-on des listeners dans un programme Java qui ne ferait que compter
de 1 à 1000 ? Réponse : non.
Trouve-ton des listeners dans une application graphique C++ ? Réponse : oui.
Ta généralisation n'est donc vraie que tant qu'on confine Java et C++ à des
domaines distincts, spécifiques.
j'ai sorti des exemples aussi specifiques que les tiens moi ?
La différence entre C++ et Java, face à la même problématique, c'est que
ce
pattern fait partie de l'api de Java, tandis qu'il ne fait pas partie de
l'api du C++, ce qui laisse le choix de tel design plutôt qu'un autre.
Qu'un
tel choix existe n'implique aucunement que ce n'est pas un idiome C++.
tu continues a confondre "listeners existants" et "listeners
courants". je n'ai jamais dit qu'il etait impossible de faire de
listeners en c++. meme si on a le CHOIX d'en faire, en pratique, peu
de personnes en font.
Je ne confonds rien du tout. En pratique, tout le monde en utilise dçs lors
que le programme gère une interface graphique, qu'il le sache ou non car
celà peut très bien être completement encapsulé dans le framework.
si c'est trop bien encapsule, c'est comme s'il n'y en avait pas. en
effet, on ne peut pas dire que la solution des listeners est courante,
si on ne sait meme pas qu'on l'exploite habituellement.
On est loin du 0% que tu sors de ton chapeau.
dis-moi alors quel est le bon pourcentage te concernant ?
Je ne vais pas à mon tour un nombre sorti de mon chapeau. Par contre, je ne
connais pas un seul framework GUI en C++ qui n'utilise pas de listeners.
Mais je n'ai pas la prétention de tous les connaitre, et je t'invite à m'en
citer qui n'en feraient pas l'usage.
celui de microsoft.
Dans tous les cas, je vais arreter ici ma contribution. Tu as eu les
réponses à ta question. Si tu décides de les ignorer car ils iraient à
l'encontre de ton a priori, qui te permettraient par exemple d'affirmer à
quel point le C++ n'est pas "propre" ou ne permet pas de faire de la POO, je
pense que personne ne peut rien pour toi.
Ce ne serait pas la première fois qu'un dogme est établi sur la base d'un
autre dogme.
Tu as eu les réponses que tu demandais. Maintenant, tu en fais ce que tu
veux.
mais elles ne repondent pas a l'enonce.
Fin de la discussion (en tout cas avec moi).
allez, ne t'en va pas fache. pour me faire pardonner, je vais te
donner la solution en c++. je viens de la trouver :
il faut mettre la liste de threads a jour. or, le thread n'a PAS LE
DROIT de contenir la liste, puisqu'il ne SAIT PAS qu'il est dans une
liste. il suffit donc de creer une classe qui sait qu'elle est dans
une liste :
class thread_qui_est_dans_une_liste : thread
{
thread[] liste; // liste dans laquelle je suis
...
}
on utilise ainsi l'HERITAGE. l'heritage est courant, meme en c++.
donc, on repond bien a l'enonce.
autre solution :
on peut donner une fonction callback au thread, afin qu'il nous
avertisse de sa fin. quand il se termine, il appelle la fonction
callback qui s'occupe de mettre la liste a jour.
cette solution ressemble a celle des listeners, sauf qu'on utilise des
callbacks. comme les callbacks sont courants en c++, on repond bien a
l'enonce.
On Tue, 11 Jan 2005 18:03:25 +0100, "Christophe Lephay" wrote:
Visiblement tu as du mal à raisonner sur les cas généraux. Tous les exemples de listeners que tu cites de Java concernent des domaines qui ne sont pas couverts par le langage C++. La notion d'interface graphique ou de thread n'est pas couverte par le langage C++.
si. pour le bouton, j'ai parle de l'api de microsoft en c++.
L'api windows définie par microsoft, y compris via ses MFC ne font pas partie du langage C++.
et alors ? ils representent une grande partie des programmes en c++. on a besoin d'eux pour pouvoir dire si les listeners sont courants ou pas en c++.
C'est comme si tu écrivais une application Java et pretendait apres coup qu'elle fait partie du standard Java. Qui plus est, même si j'ai plus utilisé les frameworks borland, il me semble bien que microsoft fait un usage intensif du modele observer. C'est le cas, par exemple, du modele document/view qui y est largement répandu.
document/view ? et "view", c'est l'observateur sans doute ? LAISSE-MOI RIRE ! "view" et la representation a l'ecran du document !
Par contre, dès qu'on doit programmer en C++ la gestion d'une interface graphique ou des threads, il n'y a pas de raison que la solution C++ diffère d'une autre utilisée en Java pour adresser le même problème.
et bien en pratique, ca differe mon cher.
C'est toi qui le dit.
c'est un fait. en pratique en c++, presque personne n'utilise d'observateur.
Le fait qu'ils soient plus fréquents en Java qu'en C++ n'est vrai que tant que tu restreins le langage à des applications *spécifiquement différentes*, ce qui fait que ta généralité ne vaut rien car elle n'est vraie que dans la spécificité des taches auxquelles tu t'attaquerais avec tel ou tel langage.
ah bon ? ma generalisation est specifique ? prouve-le.
Trouve-t-on des listeners dans un programme Java qui ne ferait que compter de 1 à 1000 ? Réponse : non.
Trouve-ton des listeners dans une application graphique C++ ? Réponse : oui.
Ta généralisation n'est donc vraie que tant qu'on confine Java et C++ à des domaines distincts, spécifiques.
j'ai sorti des exemples aussi specifiques que les tiens moi ?
La différence entre C++ et Java, face à la même problématique, c'est que ce pattern fait partie de l'api de Java, tandis qu'il ne fait pas partie de l'api du C++, ce qui laisse le choix de tel design plutôt qu'un autre. Qu'un tel choix existe n'implique aucunement que ce n'est pas un idiome C++.
tu continues a confondre "listeners existants" et "listeners courants". je n'ai jamais dit qu'il etait impossible de faire de listeners en c++. meme si on a le CHOIX d'en faire, en pratique, peu de personnes en font.
Je ne confonds rien du tout. En pratique, tout le monde en utilise dçs lors que le programme gère une interface graphique, qu'il le sache ou non car celà peut très bien être completement encapsulé dans le framework.
si c'est trop bien encapsule, c'est comme s'il n'y en avait pas. en effet, on ne peut pas dire que la solution des listeners est courante, si on ne sait meme pas qu'on l'exploite habituellement.
On est loin du 0% que tu sors de ton chapeau.
dis-moi alors quel est le bon pourcentage te concernant ?
Je ne vais pas à mon tour un nombre sorti de mon chapeau. Par contre, je ne connais pas un seul framework GUI en C++ qui n'utilise pas de listeners. Mais je n'ai pas la prétention de tous les connaitre, et je t'invite à m'en citer qui n'en feraient pas l'usage.
celui de microsoft.
Dans tous les cas, je vais arreter ici ma contribution. Tu as eu les réponses à ta question. Si tu décides de les ignorer car ils iraient à l'encontre de ton a priori, qui te permettraient par exemple d'affirmer à quel point le C++ n'est pas "propre" ou ne permet pas de faire de la POO, je pense que personne ne peut rien pour toi.
Ce ne serait pas la première fois qu'un dogme est établi sur la base d'un autre dogme.
Tu as eu les réponses que tu demandais. Maintenant, tu en fais ce que tu veux.
mais elles ne repondent pas a l'enonce.
Fin de la discussion (en tout cas avec moi).
allez, ne t'en va pas fache. pour me faire pardonner, je vais te donner la solution en c++. je viens de la trouver :
il faut mettre la liste de threads a jour. or, le thread n'a PAS LE DROIT de contenir la liste, puisqu'il ne SAIT PAS qu'il est dans une liste. il suffit donc de creer une classe qui sait qu'elle est dans une liste :
class thread_qui_est_dans_une_liste : thread { thread[] liste; // liste dans laquelle je suis
... }
on utilise ainsi l'HERITAGE. l'heritage est courant, meme en c++. donc, on repond bien a l'enonce.
autre solution :
on peut donner une fonction callback au thread, afin qu'il nous avertisse de sa fin. quand il se termine, il appelle la fonction callback qui s'occupe de mettre la liste a jour.
cette solution ressemble a celle des listeners, sauf qu'on utilise des callbacks. comme les callbacks sont courants en c++, on repond bien a l'enonce.
Vincent Lascaux
prouve-le.
en ce qui me concerne, 0% des interfaces graphiques c++ ne contiennent de listener. il en est de meme pour tout le monde, et pour toi aussi.
j'ai plusieurs threads qui tournent. chaque thread est un objet. dans le programme principal, j'ai une liste de tous ces threads (dans un tableau par exemple).
supposons qu'un thread se termine. comment peut-il prevenir le programme principal, afin qu'il enleve sa reference de la liste de threads ?
solution 1 (mauvaise) : le thread a une reference vers la liste, et il peut la modifier. or, cela est absurde en programmation objet; le thread (qui est un objet) n'a pas a contenir une reference vers la liste.
solution 2 (mauvaise) : la liste est une variable globale. le thread peut donc y avoir acces. or, une fois de plus, cela est absurde en programmation objet; le thread n'a pas a s'occuper de mettre la liste de threads a jour. il n'est meme pas cense savoir qu'il est repertorie dans une liste.
existe-t-il une solution propre et non-marginale a ce probleme de conception objet ?
Tu ajoutes un ID à chaque objet thread, comme ça tu les retrouves facilement dans ton tableau :p
-- Daft
Your lucky number is 3552664958674928. Watch for it everywhere !
luc2 wrote:
j'ai plusieurs threads qui tournent. chaque thread est un objet. dans
le programme principal, j'ai une liste de tous ces threads (dans un
tableau par exemple).
supposons qu'un thread se termine. comment peut-il prevenir le
programme principal, afin qu'il enleve sa reference de la liste de
threads ?
solution 1 (mauvaise) : le thread a une reference vers la liste, et il
peut la modifier. or, cela est absurde en programmation objet; le
thread (qui est un objet) n'a pas a contenir une reference vers la
liste.
solution 2 (mauvaise) : la liste est une variable globale. le thread
peut donc y avoir acces. or, une fois de plus, cela est absurde en
programmation objet; le thread n'a pas a s'occuper de mettre la liste
de threads a jour. il n'est meme pas cense savoir qu'il est repertorie
dans une liste.
existe-t-il une solution propre et non-marginale a ce probleme de
conception objet ?
Tu ajoutes un ID à chaque objet thread, comme ça tu les retrouves facilement
dans ton tableau :p
--
Daft
Your lucky number is 3552664958674928. Watch for it everywhere !
j'ai plusieurs threads qui tournent. chaque thread est un objet. dans le programme principal, j'ai une liste de tous ces threads (dans un tableau par exemple).
supposons qu'un thread se termine. comment peut-il prevenir le programme principal, afin qu'il enleve sa reference de la liste de threads ?
solution 1 (mauvaise) : le thread a une reference vers la liste, et il peut la modifier. or, cela est absurde en programmation objet; le thread (qui est un objet) n'a pas a contenir une reference vers la liste.
solution 2 (mauvaise) : la liste est une variable globale. le thread peut donc y avoir acces. or, une fois de plus, cela est absurde en programmation objet; le thread n'a pas a s'occuper de mettre la liste de threads a jour. il n'est meme pas cense savoir qu'il est repertorie dans une liste.
existe-t-il une solution propre et non-marginale a ce probleme de conception objet ?
Tu ajoutes un ID à chaque objet thread, comme ça tu les retrouves facilement dans ton tableau :p
-- Daft
Your lucky number is 3552664958674928. Watch for it everywhere !
Patrick Mézard
luc2 wrote:
j'ai plusieurs threads qui tournent. chaque thread est un objet. dans le programme principal, j'ai une liste de tous ces threads (dans un tableau par exemple).
Il n'y a pas de threads en C++. Peut-être pourras-tu trouver ta réponse sur comp.programming.threads, comp.object (voire comp.object.moderated qui sait) ou sur fr.comp.objet.
Patrick Mézard
luc2 wrote:
j'ai plusieurs threads qui tournent. chaque thread est un objet. dans
le programme principal, j'ai une liste de tous ces threads (dans un
tableau par exemple).
Il n'y a pas de threads en C++.
Peut-être pourras-tu trouver ta réponse sur comp.programming.threads,
comp.object (voire comp.object.moderated qui sait) ou sur fr.comp.objet.
j'ai plusieurs threads qui tournent. chaque thread est un objet. dans le programme principal, j'ai une liste de tous ces threads (dans un tableau par exemple).
Il n'y a pas de threads en C++. Peut-être pourras-tu trouver ta réponse sur comp.programming.threads, comp.object (voire comp.object.moderated qui sait) ou sur fr.comp.objet.
