mise a jour d'une liste de threads

On Mon, 10 Jan 2005 19:45:22 +0100, luc2 <luc2@nospam.invalid>:

From: luc2

Non ! _Le_ luc2 ? Le vrai ? Celui de <http://lucii.free.fr/> ?

Okaeri nasai !


--
;-)

ma question n'a pas l'air de vous inspirer. je vais vous donner un
exemple de solution en java :

on donne un listener au thread pour qu'il nous previenne quand il se
termine. quand le listener se declenche, il met la liste de threads a
jour. c'est tout.

les listeners sont couramment utilises en java. c'est donc une
solution propre et non-marginale. de plus, elle respecte les principes
de la programmation objet.

les listeners ne sont pas courants en c++. donc, ma question est
toujours la meme : comment resoudre le probleme en c++, tout en
respectant dans les principes de la programmation objet ? maintenant
que vous avez eu un exemple de ce que j'attendais comme solution, ce
sera de la rigolade pour vous d'y repondre.

On Mon, 10 Jan 2005 19:45:22 +0100, luc2 <luc2@nospam.invalid> 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 ?

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.

Pourquoi pas ? C'est justement parce que c'est un objet qu'il
peut s'inscrire et se désinscrire dans d'autres objets.

En fait, j'ai souvent le cas où une classe maintient un registre
statique de ses instances, accésible au moyen d'une fonction
statique. Solution qui me semble convenir parfaitement ici.

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.

Je ne suis pas tellement pour la variable globale ; justement,
parce qu'en programmation objet, il n'y a que l'objet thread qui
doit pouvoir s'inscrire et se désinscrire.

existe-t-il une solution propre et non-marginale a ce probleme
de conception objet ?

Je regrette, mais je ne vois pas le problème. S'inscrire et se
désinscrire me semblent des comportements tout à fait typique
d'un objet.

--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

luc2 wrote:

ma question n'a pas l'air de vous inspirer. je vais vous donner un
exemple de solution en java :

on donne un listener au thread pour qu'il nous previenne quand il se
termine. quand le listener se declenche, il met la liste de threads a
jour. c'est tout.

Je ne connais pas trop Java mais le terme "listener" me fait penser à
une concrétisation d'un pattern "Observateur".
Dans le cas présent, le thread est le sujet observé et le programme
principal est l'observateur.

les listeners sont couramment utilises en java. c'est donc une
solution propre et non-marginale. de plus, elle respecte les principes
de la programmation objet.

les listeners ne sont pas courants en c++. donc, ma question est
toujours la meme : comment resoudre le probleme en c++, tout en
respectant dans les principes de la programmation objet ? maintenant
que vous avez eu un exemple de ce que j'attendais comme solution, ce
sera de la rigolade pour vous d'y repondre.

Utiliser un pattern Observateur est très courant en C++...

On Mon, 10 Jan 2005 19:45:22 +0100, luc2 <luc2@nospam.invalid> 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 ?

luc2 wrote:

ma question n'a pas l'air de vous inspirer. je vais vous
donner un exemple de solution en java :

on donne un listener au thread pour qu'il nous previenne quand
il se termine. quand le listener se declenche, il met la liste
de threads a jour. c'est tout.

Je n'ai pas trouvé ça dans Java. Il n'y a aucun Listener pour
quoique ce soit des Threads.

L'idée est intéressante pour une classe générale de Thread. Une
interface qui permet d'être notifié en cas de mort d'un thread.
Mais je ne l'ai jamais vu, ni en Java ni en C++. Il faut croire
donc qu'on n'en a pas aussi souvent besoin que ça.

La plupart des classes Thread que j'ai vu en C++ ont bien une
fonction statique pour obtenir la liste des threads actifs. En
Java, il y a une liste par ThreadGroup, plutôt qu'une liste
globale pour tout le monde ; ce n'est donc pas une fonction
statique, mais sinon, c'est le même principe.

les listeners sont couramment utilises en java. c'est donc une
solution propre et non-marginale. de plus, elle respecte les
principes de la programmation objet.

Le fait d'utiliser les listeners n'a rien à voir avec le
langage. C'était courant en C++ avant même que le Java existait,
et courant en Smalltalk avant que le C++ ait vu le jour.

Évidemment, il ne sont pas utilisé dans tous les programmes ; on
s'en sert (ou en Java ou en C++) que dans les cas où la solution
convient. (Si on trouve qu'ils sont plus fréquents en Java,
c'est peut-être que le Java n'est utilisable que dans un petit
nombre de domaines, et que par hazard, les listeners conviennent
dans tous ces domaines. Mais en fait, je ne me rappelle pas d'en
avoir vue dans des JSP, qui est quand même un domaine de
prédilection de Java.)

les listeners ne sont pas courants en c++.

Ça dépend du domaine d'application. Ils sont très courants où
ils conviennent.

donc, ma question est toujours la meme : comment resoudre le
probleme en c++, tout en respectant dans les principes de la
programmation objet ?

Et ma question est toujours la même : où est le problème ? J'ai
expliqué une solution ; par hazard, il se rapproche beaucoup à
la solution offerte en java.lang.Thread, à l'exception près
qu'il y a un seul ThreadGroup.

maintenant que vous avez eu un exemple de ce que j'attendais
comme solution, ce sera de la rigolade pour vous d'y repondre.

Mais si tu sais ce que tu veux comme solution, pourquoi la
question ? Si tu veux un listener sur la fin d'un Thread, c'est
assez facile à implémenter. L'avantage que les Thread ne font
pas partie de la bibliothèque standard, c'est que tu peux les
implémenter comme tu veux. (Le désavantage, évidemment, c'est
qu'il faut les implémenter, et que chacun les implémente un peu
différemment.)

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

"luc2" <luc2@nospam.invalid> a écrit dans le message de news:
5cg7u09vj6cehac576i6vgg17lm3s1hovr@4ax.com...

On Mon, 10 Jan 2005 22:45:16 +0100, James Kanze <kanze@none> wrote:

Pourquoi pas ? C'est justement parce que c'est un objet qu'il
peut s'inscrire et se désinscrire dans d'autres objets.

mais il ne DOIT PAS etre prevu pour s'inscrire et se desinscrire des
autres objets. un objet coherent n'a pas a savoir par qui il est
reference.

Mais en pratique, un objet est rarement "cohérent" *par lui-même*. La
finalité d'un objet, c'est assez souvent de collaborer avec d'autres objets.
D'une manière ou d'une autre, le listener doit bien être tenu informé des
objets qu'il écoute. Soit il les créera ou les détruira de lui-même, auquel
cas l'objet lui-même n'aura pas besoin de s'inscrire et se désinscrire, soit
la création de l'objet se fait via une api qui echape au listener, auquel
cas ce sera à l'objet écouté de s'enregistrer/désenregistrer.

La cohérence, ça consiste avant tout à trouver une solution qui fournisse la
fonctionnalité attendue en fonction des différentes contraintes de
l'environnement.

On Mon, 10 Jan 2005 22:45:16 +0100, James Kanze <kanze@none> 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.

Pourquoi pas ? C'est justement parce que c'est un objet qu'il
peut s'inscrire et se désinscrire dans d'autres objets.

mais il ne DOIT PAS etre prevu pour s'inscrire et se desinscrire des
autres objets. un objet coherent n'a pas a savoir par qui il est
reference.

suppose que tu fasses une serie de boutons que l'on peut cliquer.
chaque bouton est un objet. si on fait une liste de ces boutons dans
le programme principal, chaque bouton ne DOIT PAS savoir qu'il est
reference par une liste.

class Bouton
{
Bouton[] liste_de_boutons; // liste de boutons a mettre a jour

...
}

et pourquoi ne faut-il pas qu'il y ait une liste de boutons dans la
classe bouton ? parce que le bouton n'est pas forcement dans une liste
! donc la classe NE DOIT PAS contenir de liste !

faire une classe, c'est donner sa definition. dans la definition d'un
bouton, rien ne dit qu'il fait forcement partie d'une liste a mettre a
jour. si on veut faire une liste a mettre a jour, c'est le programme
principal qui doit se debrouiller pour gerer ca. le bouton n'a pas a
le savoir.

En fait, j'ai souvent le cas où une classe maintient un registre
statique de ses instances, accésible au moyen d'une fonction
statique. Solution qui me semble convenir parfaitement ici.

alors tes programmes ne respectent pas les principes de la
programmation objet.

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.

Je ne suis pas tellement pour la variable globale ; justement,
parce qu'en programmation objet, il n'y a que l'objet thread qui
doit pouvoir s'inscrire et se désinscrire.

pourtant, ce que tu fais avec ta classe statique revient au meme que
d'utiliser une variable globale.

existe-t-il une solution propre et non-marginale a ce probleme
de conception objet ?

Je regrette, mais je ne vois pas le problème.

c'est bien ce que je constate. je suis decu du premier lot de reponses
que j'ai eu. vous ne semblez pas comprendre l'esprit de la
programmation objet.

un ami m'a dit qu'il etait CONTRE la programmation objet, parce que,
dans 99% des cas, les programmes sont sales, les gens ne savent pas
programmer en objet, les gens ne programment pas reellement en objet,
ils font tout un bazar de spaghettis... je commence a comprendre ce
qu'il voulait dire, meme si je pense toujours qu'il a tort de renoncer
a la programmation objet.

luc2 <luc2@nospam.invalid> writes:

On Mon, 10 Jan 2005 22:45:16 +0100, James Kanze <kanze@none> 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.

Pourquoi pas ? C'est justement parce que c'est un objet qu'il
peut s'inscrire et se désinscrire dans d'autres objets.

mais il ne DOIT PAS etre prevu pour s'inscrire et se desinscrire des
autres objets. un objet coherent n'a pas a savoir par qui il est
reference.

Ah? La conception est toujours une affaire de compromis entre
differents objectifs contradictoires, dont la simplicite et la
generalite. Si tous les objets d'une classe doivent etre reference
par un autre objet, le plus simple est de les faire s'inscrire dans
les constructeurs et desinscrire dans le destructeur. Une structure a
observateur (ou c'est l'autre objet qui s'inscrit comme observateur et
tous les observateurs qui sont avertis d'evenements) est plus generale
(on peut s'en servir pour d'autres choses, un objet peut se retrouver
dans plusieurs listes, ...) mais plus complexe (comment garantir par
exemple le fait que tout objet soit inscrit? On ajoute une factory?
Ok, mais ca empeche de creer des objets sur le tas.) et cette
complexite est peut-etre inutile. C'est rare qu'il y ait des
solutions uniques a un probleme, il y a souvent plusieurs solutions
qui offrent des compromis differents.

suppose que tu fasses une serie de boutons que l'on peut cliquer.
chaque bouton est un objet. si on fait une liste de ces boutons dans
le programme principal, chaque bouton ne DOIT PAS savoir qu'il est
reference par une liste.

L'analogie entre boutons et threads me semblent fortement tirees par
les cheveux. Ca me n'etonne pas du tout qu'ils aient besoin de
compromis differents, donc de solution differentes. Oui la solution
la plus generale peut vraissemblablement faire l'affaire, mais elle
n'est pas pour autant la meilleure.

En fait, j'ai souvent le cas où une classe maintient un registre
statique de ses instances, accésible au moyen d'une fonction
statique. Solution qui me semble convenir parfaitement ici.

alors tes programmes ne respectent pas les principes de la
programmation objet.

Cela reste a mon avis a prouver mais en admettant cela en quoi est-ce
un probleme? La conception OO est un outil, pas une religion. Quand
un outil n'est pas celui qu'il me faut, j'en prend un autre.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

luc2 <luc2@nospam.invalid> 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 ?

ta liste est elle meme un timer (thread) qui verifie periodiquement que
sa liste de thread est a jour.
--
bruno Causse
http://perso.wanadoo.fr/othello

On Mon, 10 Jan 2005 23:13:31 +0100, Olivier Azeau <john@doe.com>
wrote:

ma question n'a pas l'air de vous inspirer. je vais vous donner un
exemple de solution en java :

on donne un listener au thread pour qu'il nous previenne quand il se
termine. quand le listener se declenche, il met la liste de threads a
jour. c'est tout.

Je ne connais pas trop Java mais le terme "listener" me fait penser à
une concrétisation d'un pattern "Observateur".
Dans le cas présent, le thread est le sujet observé et le programme
principal est l'observateur.

c'est exactement ca.

les listeners sont couramment utilises en java. c'est donc une
solution propre et non-marginale. de plus, elle respecte les principes
de la programmation objet.

les listeners ne sont pas courants en c++. donc, ma question est
toujours la meme : comment resoudre le probleme en c++, tout en
respectant dans les principes de la programmation objet ? maintenant
que vous avez eu un exemple de ce que j'attendais comme solution, ce
sera de la rigolade pour vous d'y repondre.

Utiliser un pattern Observateur est très courant en C++...

je crois que tu confonds "etre courant" et "exister". les observateurs
existent en c++, mais ils ne sont pas courants. demande a un
programmeur de c++ s'il sait ce qu'est un observateur, il ne saura
pas, il n'en aura jamais utilise, tandis qu'en java, il y a cent
chances sur cent qu'il sache ce que c'est qu'un listener.

en java, il est evident que les listeners sont courants : il y en a
partout dans l'api du java. on est donc obliges de s'en servir.

d'autre part, je m'etonne qu'il n'y ait pas d'autre solution que de
faire un listener/observateur pour resoudre le probleme.